tag:blogger.com,1999:blog-50806381585474779142024-02-21T02:21:28.150-05:00Modular ITInformation and opinion about the trend toward software modularization, especially as it relates to the OSGi framework.Eric Newcomerhttp://www.blogger.com/profile/06128310302941718982noreply@blogger.comBlogger18125tag:blogger.com,1999:blog-5080638158547477914.post-85140182434633414642009-08-03T16:03:00.011-04:002009-08-07T12:18:41.486-04:00Purity or Compromise?<span style="font-style: italic;">Update August 7: David Bosschaert has started a <a href="http://osgithoughts.blogspot.com/">new OSGi blog</a> for topics related to the EEG direction etc. I recommend every reader of this blog to check it for updates on what's happening at the EEG from here on. </span><br /><br /><span style="font-style: italic;">Also a colleague pointed out that my diagram and text below is a bit optimistic about the availability of the Blueprint Container as a development model for Web apps in the near future. The current version of the design (documented in RFC 66) does not actually address this, although a future version is definitely expected to. The current version of the design simply standardizes the deployment of a WAR file onto an OSGi framework, which is a good first step but not the end goal.</span><br /><span style="font-style: italic;"> </span><br /><br />This is my last blog as co-chair of the <a href="http://www.osgi.org/EEG/HomePage">OSGi EEG</a>. In fact as of last Friday <a href="http://coderthoughts.blogspot.com/">David Bosschaert</a> has officially taken over the position. But I was co-chair for last week's face to face meeting in Dublin, so I'll write a bit about what happened.<br /><br />We have completed the R4.2 Core and Compendium specifications, which were submitted to the 45-day member review July 14. Assuming the vote goes well, publication will be early September. The Compendium includes the new Remote Services and Blueprint Container specifications, and the Core includes several enhancements and extensions resulting primarily from requirements gathered at the <a href="http://www.osgi.org/blog/2006/09/enterprise-workshop.html">enterprise workshop</a>.<br /><br />That leaves the R4.2 Enterprise Profile, scheduled for release in December, for the EEG to work on. The major part of this work will be mapping various Java EE specifications to OSGi, such as JTA, JMX, JDBC, JNDI, JPA, and last but certainly not least Web apps. The profile will likely also include (by reference) the Blueprint Container and Remote Services parts of the R4.2 compendium.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhXDtEI_caqXlsG0z4WX7UkBCsZhd_l4in0p2p9vCpSVQ_hrn1aZsJ3BeULM5GXDq2Vvk7PnB8MeC-e4fUdM7MpOodmaFFuabulU3kk-OZtkhU7ndUJNWPF_gmGiVPhttrhJBpIAat3Rw/s1600-h/Release+Planning.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 300px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhXDtEI_caqXlsG0z4WX7UkBCsZhd_l4in0p2p9vCpSVQ_hrn1aZsJ3BeULM5GXDq2Vvk7PnB8MeC-e4fUdM7MpOodmaFFuabulU3kk-OZtkhU7ndUJNWPF_gmGiVPhttrhJBpIAat3Rw/s400/Release+Planning.jpg" alt="" id="BLOGGER_PHOTO_ID_5365843729384865618" border="0" /></a><span style="font-size:130%;"><span style="font-weight: bold;">Enterprise Profile Summary Diagram</span></span><br /><br />I created the diagram to illustrate what we're trying to achieve, and presented it last week to help facilitate the planning part of the meeting to provide context around prioritizing the remaining work (it is not part of any formal OSGi document). Time is getting tight ;-) The <a href="http://www.osgi.org/Repository/HomePage">OBR</a> continuation is for example looking more like an R5 item at this point.<br /><br />The main point is that defining a mapping for Web apps (.WAR files) using the Blueprint Container as the development environment and JDBC/JPA for persistence would seem to meet the requirements for a large number of enterprise applications, and represent a good starting point for the initial release of the Java EE mapping work.<br /><br />What I call "system services" on the side represents the optional use of additional Java EE components (such as transactions, security, directory, and management) that such a Web application might choose to use if it needs them, along with Remote Services for invoking OSGi services deployed in other frameworks.<br /><br />Because the Java EE components were not designed for OSGi, they depend on mechanisms such as context classloaders and file URLs to instantiate required classes and resources. Which of course breaks fundamental OSGi abstractions, since the framework is responsible for loading classes and managing the access to required resources. We had a very lively debate on the subject of how much the Java EE components should be required to change vs how much the OSGi specification should have to change. We did not reach consensus.<br /><br />I think the solution may be found in a kind of mapping layer or adapter mechanism (conceptually similar to JCA), like the one in <a href="http://www.springsource.com/products/dmserver">SpringSource dm Server</a>, or in the <a href="http://servicemix.apache.org/kernel/">ServiceMix Kernel</a> (which has been moved to a separate project called <a href="http://felix.apache.org/site/apache-felix-karaf.html">Apache Karaf</a>). But all I can really say at this point is that I will be very interested in hearing the results of the ongoing discussion.<br /><br />Next Monday I start my job as an integration architect for Credit Suisse in New York. And they are not members of the OSGi Alliance - at least not yet ;-)<br /><br />Thanks to everyone who followed the posts on this blog, and who participated in the discussion. Please keep it going! And support David and Tim and the rest of the EEG members...Eric Newcomerhttp://www.blogger.com/profile/06128310302941718982noreply@blogger.com2tag:blogger.com,1999:blog-5080638158547477914.post-25519308997100559862009-07-22T17:08:00.007-04:002009-07-25T10:44:55.924-04:00R4.2: Next release of OSGi, and what's next<a href="http://alblue.blogspot.com/">Alex Blewitt</a> posted <a href="http://www.infoq.com/news/2009/07/osgi-next-release">a great write up</a> to <a href="http://www.infoq.com/">InfoQ</a> of <a href="http://www.aqute.biz/Main/HomePage">Peter Kriens</a>' recent <a href="http://skillsmatter.com/podcast/os-mobile-server/osgi-the-next-enterprise-release-by-peter-kriens-osgi-alliance-director-of-technology">presentation on the next release of OSGi</a>, which is called R4.2.<br /><br />This release started in September 2006 with the <a href="http://www.osgi.org/blog/2006/08/osgi-enterprise-workshop.html">OSGi Enterprise Workshop</a>. When I volunteered to co-chair the <a href="http://www.osgi.org/EEG/HomePage">EEG</a> in December I remember being told it would take about two years to get the release out. Pretty close I guess...<br /><br />The presentation is kind of long (112 minutes), but well worth watching if you're interested in OSGi, or in hearing Peter's view of what's gone wrong with the Java Modularity initiative as currently defined in the <a href="http://jcp.org/en/jsr/detail?id=294">JSR 294</a> community (of which he is a member) and how to fix it.<br /><br />The new features in R4.2 are spread across the Core and Compendium parts of the <a href="http://www.osgi.org/Specifications/HomePage"></a>, but the major changes in R4.2 are being driven by enterprise requirements, primarily represented in the Remote Services (formerly RFC 119) and Blueprint Container (formerly RFC 124) additions to the Compendium. The new service registry hooks in the core were similarly based on enterprise requirements (specifically from the Remote Services work).<br /><br />But of course not done with the enterprise requirements. The EEG is meeting again next week, primarily to continue working on the Java EE component mappings Peter briefly references, which we hope to publish at the end of the year in an "Enterprise Profile" document, and start thinking about what's going to be in R5, scheduled for June 2010.<br /><br />And we need to continue working on application metadata and the OSGi Bundle Repository definitions (despite the fact that Peter doesn't want to define an application ;-). The main reason for this is to provide a better foundation for the kind of development lifecycle tooling commonly used for enterprise application development.<br /><br />We have made a good start, but there's lots more to do. Meanwhile the debate continues about whether or not it's a good idea to use OSGi for developing enterprise applications directly, or only indirectly through its incorporation in products.<br /><br />R4.2 represents a significant step in this direction, but we still have a lot to do.Eric Newcomerhttp://www.blogger.com/profile/06128310302941718982noreply@blogger.com2tag:blogger.com,1999:blog-5080638158547477914.post-12885753957528590532009-06-18T18:04:00.015-04:002009-06-21T11:54:51.697-04:00Kill Project Jigsaw Now. Please!We need to relieve poor Alex Buckley from his suffering. What he is <a href="http://modualrit.blogspot.com/2009/06/osgi-standard-questions.html?showComment=1245347991716#c9181100485304475503">complaining about</a> here is due to the fact that he could not answer the very first (and most important) question put to him by the OSGi expert group: "Why didn't you start with OSGi?"<br /><br />Furthermore, during that morning's debate, the OSGi members managed to completely invalidate every technical justification for why it's necessary for <a href="http://openjdk.java.net/projects/jigsaw/">Project Jigsaw</a> to reinvent OSGi (it clearly isn't).<br /><br />To be fair, Alex has been put in a very bad position as <a href="http://jcp.org/en/jsr/detail?id=294">JSR 294</a> spec lead. It's widely accepted that modular programming could be improved through extensions to the Java language, and the work in this direction to date on JSR 294 has been well received (with the exception that it has not defined a mapping to OSGi of course). But the problem for JSR 294 going to continue to be that there is no technical reason for mapping to Project Jigsaw instead of OSGi.<br /><br />It would be so much easier on Alex -- and on all the rest of us interested in Java modularity -- if we could just kill Project Jigsaw. And the sooner the better.<br /><br />It would also save James Gosling from making further <a href="http://www.eweek.com/c/a/Application-Development/Gosling-Whats-Good-for-Google-May-Not-be-Good-for-Java-254444/1/">embarassing statements</a> about OSGi. (OSGi is not fat, is not big or bloated, and were Project Jigsaw to live it would have to duplicate most of what's in OSGi anyway.)<br /><br />There are other good reasons for killing Project Jigsaw. But the main reason is that the OSGi specification already defines a perfectly good, mature, tested, and widely adopted modularity standard. It's been around for more than 10 years, has a <a href="http://jcp.org/en/jsr/detail?id=291">JSR</a> and an open process through which the leading Java vendors participate actively (unlike Project Jigsaw), and has gone through <a href="http://www.osgi.org/Specifications/HomePage">several major iterations</a> (R4.2 is very nearly completed as well).<br /><br />OSGi already has been incorporated successfully into thousands of projects and products, and is endorsed by nearly every Java vendor (including Sun, or should I say at least the part of Sun working on <a href="http://weblogs.java.net/blog/ss141213/archive/2008/04/glassfish_v3_on.html">Glassfish</a>).<br /><br />The industry does not need another Java modularity standard. That's like having two competing alphabets from which to compose words. It just doesn't make sense. It is counterproductive, especially when the IT world needs to focus on reducing cost and improving flexibility. No wonder Alex is pulling his hair out.<br /><br />The Jigsaw guys had their 15 minutes of fame at Java One. For Alex's sake, and the sake of everyone else involved in Java modularity, let's kill it. Now. Please.Eric Newcomerhttp://www.blogger.com/profile/06128310302941718982noreply@blogger.com7tag:blogger.com,1999:blog-5080638158547477914.post-35702037317893459142009-06-11T11:17:00.003-04:002009-06-11T12:36:43.782-04:00OSGi Standard QuestionsIn my role as OSGi Enterprise Expert Group co-chair, I get a lot of questions about OSGi. I thought I'd post some of the more interesting ones here.<br /><br />First, I was very surprised to hear someone from a large end-user organization say that they would be very interested in using OSGi, if only it were a standard.<br /><br />The OSGi Specification is as much a standard as any specification developed in the Java Community Process, and more than some. I interpret this as what this person's Java EE vendor has been telling them, privately and in confidence of course, about OSGi.<br /><br />The OSGi Specification started as <a href="http://jcp.org/en/jsr/detail?id=8">JSR 8</a> back in 1999, and the current version (R4.2) is, as previous versions have been, an evolution of the original work, which was formally handed off from the JCP to the OSGi Alliance at the time. Certainly you could say the scope of modularizing Java (which is the essence of the OSGi Specification, after all) is potentially very broad, and you might question whether its entire potential scope has been standardized.<br /><br />But you can also look at <a href="http://jcp.org/en/jsr/detail?id=291">JSR 291</a> and see that the previous version of the OSGi Specification (R4.1) has already been officially adopted as a Java specification for a dynamic modularity system. The <a href="http://www.osgi.org/Main/HomePage">OSGi Alliance</a> is, if anything, more open than the <a href="http://jcp.org/en/home/index">Java Community Process</a> (and yes, I have participated in each, both at the technical level and the board level - in the case of JCP the former IONA rep elected to the EC reported to me).<br /><br />Sun has never given up its control over the JCP or any specification it chooses to take the lead on. Anyone can join the OSGi Alliance and participate equally in the development of its specification. This is part of what is meaningful about a standard, that its future direction is open for anyone to participate. No vendor wants to invest a lot in implementing a standard that one of your competitors effectively controls the future of. (Thus the current controversy around the JCP and the whole debate about the future of the Java industry, whether it will continue to fragement etc.)<br /><br />I suspect what this person really meant was "OSGi is not part of Java EE." That is true. But that is not necessarily a bad thing. I mean, having Java EE based on the OSGi Framework would be great. But having the future of OSGi under the control of the JCP, even to the extent of meeting the requirements of becoming part of Java EE, might not be very helpful to it (or to the future of modular programming in Java).<br /><br />Before I get on to the next obvious question about <a href="http://openjdk.java.net/projects/jigsaw/">Project Jigsaw</a> (which you will notice studiously avoids mentioning OSGi), I want to point out that all Java EE vendors have already adopted OSGi, and built their app servers internally on it (well except JBoss, who has sort of tried to bolt OSGi onto their own microkernel, which seems weird). But they are, so far at least, advising against their customers obtaining the same benefits that motivated them to adopt the OSGi programming model internally - apparently including the argument that "OSGi is not a standard." This does not make sense, at least not for the consumers.<br /><br />AFIAK Project Jigsaw is Sun's latest attempt to re-invent OSGi, or in any case block OSGi or create a substitute they can control. I understand the potential benefits of modularizing the language itself, and I know that the <a href="http://jcp.org/en/jsr/detail?id=294">JSR 294</a> spec lead (<a href="http://blogs.sun.com/abuckley/">Alex Buckley</a>) spent some time liasing with the OSGi EEG (even attending a meeting and taking the abuse, pretty well anyway - I give him credit for trying to do the right thing), and that JSR 294 (which also studiously avoids mentioning OSGi) in theory is not strictly a documentation exercise for whatever they come up with in the OpenJDK project (which by the way is open in the same sense that the JCP is open - meaning it is under Sun's control), and that also in theory the modularity layer is "pluggable." All of this is sort of meant to indicate that OSGi compatibility or mapping is something the Project Jigsaw folks have in mind, if they are not actually working on it (which they are not as far as I can tell, and they also say nothing about this publicly - apparently only when someone brings up the topic of OSGi).<br /><br />I was not at Java One this year, so I may have the wrong impression sitting remotely as I am, but my understanding is that the Project Jigsaw talks and demos did not mention OSGi. Nor did the descriptions of the plans for Java 7. So the short answer to the question of whether Project Jigsaw is a threat to Java modularity is that yes, it is.<br /><br />One more thing to add - I have been following the <a href="http://mail.openjdk.java.net/mailman/listinfo/jigsaw-dev">Project Jigsaw public email list</a>, and from what I could gather what was presented at Java One was more or less equivalent to what they could manage to get done by then. And while the demo looked interesting, and certainly seems to prove they got something working, it also is pretty scary when you think how far away that is from what's already available in the OSGi Framework.Eric Newcomerhttp://www.blogger.com/profile/06128310302941718982noreply@blogger.com10tag:blogger.com,1999:blog-5080638158547477914.post-52939407040116003872009-06-01T16:31:00.003-04:002009-06-01T19:08:39.272-04:00Report from OSGi Bundlefest/EEG F2F<div>Sorry for the delay posting. Here's a report back from the OSGi Bundlefest & <a href="http://www.osgi.org/EEG/HomePage">EEG</a> face to face held the week of May 11 in Montpellier France.</div><div> </div><br /><div>As some of you may remember, the <a href="http://www.osgi.org/Main/HomePage">OSGi Alliance</a>'s specification work is aligned with the Eclipse release schedule, since <a href="http://www.eclipse.org/equinox/">Eclipse Equinox</a> is the reference implementation for the core spec. We had originally been trying to complete our work in time for an end of June publication, to coincide with the release of Equinox. </div><div> </div><br /><div>But we are running into some difficulties - not with the core specification, but with the compendium. In particular, I think it's fair to say that the specification writing phase of the OSGi Alliance process has turned out to be more difficult than anyone expected. In fact the difficulties spilled over into the <a href="http://www.osgi.org/blog/2009/05/processes.html">blogosphere</a> (not that I am trying to reopen the debate about how much change should be allowed or anything!).</div><div> </div><br /><div>The OSGi Alliance is unique among standards organizations and consortia I've contributed to in the past, in part for its informal, collegial environment, but mainly because the Alliance employs a specification editor (currently <a href="http://www.aqute.biz/Main/HomePage">Peter Kriens</a>) who is responsible for including the member-driven designs into the existing specification.<br /></div><div> </div><br /><div>As a minor refresher, the OSGi Alliance <a href="http://www.osgi.org/WG/HomePage">specification development process</a> begins with the formalization of requirements into documents called Request for Proposal (RFPs). When it believes an RFP is complete, the expert group submits it to the requirements group for approval (rarely does an RFP get rejected once an EG submits it - actually this has not happened to the EEG). Once an RFP is approved, one or more solutions to the requirements can be created, in the form of a design document called a Request for Comment (RFC). An RFC has to be approved by the expert group, and once it is, the RFP is submitted to the specification process for finalization. </div><div> </div><br /><div>This last part of the process represents a signficant difference between how the OSGi Alliance works and other bodies work. Especially since the same person has been writing the OSGi specification for about 10 years. The specifications are consistent and very good, as a result. However, most people experienced in standards participation (myself included) find this part of the process takes a little getting used to.<br /></div><div> </div><br />Overall - and I have explicitly asked several other EG members about this - the result of following this step in the process is an improvement over what was in the RFCs. However the RFCs are sometimes the way they are due to compromises among EG members, and the specification process (which is, once again, a good thing) has a tendency to bring things like this back to the surface, especially when the design compromises end up decreasing the quality of the specification. Which, as I've said, has been very good for about a decade now, and we certainly want to preserve the level of quality. On top of all of this, of course, is the fact that OSGi has been around for more than a decade now, and has a very real reference implementation in Equinox, which is used in literally hundreds of products and technologies.<br /><div> </div><br /><div>The two designs we are trying very hard to get into the R4.2 Compendium are the Blueprint service (RFC 124) and Remote Services (RFC 119). We had scheduled the bundlefest a while ago to work on RIs and TCKs, on the assumption we'd be done with the majority of the specification work and we could focus on finishing the code bits. Instead, I had to prioritize the specification work ahead of all other work, which created a very ad hoc kind of agenda, one that changed daily - in fact, sometimes several times a day.<br /></div><div> </div><br /><div>At the end of the week we had made some good progress on the specifications - in particular resolving some fairly significant issues that were uncovered - and some of the members also managed to get some coding done. Each day closed with two hour-long calls - one to review the days' discussion for those who were unable to attend (travel budgets are as tight as I've ever seen them), and another to discuss topics still in the requirements or design stage (we are trying to keep the OBR/metadata discussions moving and complete more of the Java EE component mappings in time for the planned end 2009 enterprise profile release). </div><div> </div><br /><div>We have decided to release the core and compendium specifications separately - the R4.2 core specification being implemented by Equinox 3.4 in <a href="http://www.eclipse.org/ganymede/">Eclipse Ganymede</a> released this month - and the compendium needing a bit more time. Currently we are aiming to get it all wrapped up by the end of June for publication in August - fingers crossed. </div><div> </div><br /><div>It was chilly and rainy the whole week, which I suppose was just as well since we had to be in the meeting room all day (except for the famous lunches of course ;-). Saturday was a beautiful day, however, which was lucky for me and for Peter Peshev, since we'd planned to dedicate the day to tourism. We had a great time <a href="http://picasaweb.google.com/enewcomer/FranceMay09#">visiting Pont du Gard, Avignon, and Chateauneuf du Pape</a> - eating cherries bought from roadside stands all the way.</div><br /><br /><div> </div><br /><div> </div><br /><div> </div>Eric Newcomerhttp://www.blogger.com/profile/06128310302941718982noreply@blogger.com0tag:blogger.com,1999:blog-5080638158547477914.post-32018526221265275752009-04-25T15:53:00.001-04:002009-04-29T19:53:19.310-04:00Summary of EEG Provisioning DiscussionDuring a discussion on Twitter about provisioning OSGi based applications, I mentioned this was a topic of debate at the <a href="http://www.osgi.org/EEG/HomePage">Enterprise Expert Group</a> and was asked if I could post some details. Because of OSGi Alliance confidentiality rules, it's not possible to publish details. But I can give a general summary.<br /><br />As I may have mentioned before, one of the biggest gaps we identified in the enterprise release is improved support for the enterprise application development lifecycle (developing, building, testing, deploying, updating etc.). While some of this is going to depend on specific tooling extensions, some aspects are things the EEG can help through standardization. One of those is the OSGi Bundle Repository, otherwise known as RFC 112, which is largely based on the work Richard Hall did with the <a href="http://oscar-osgi.sourceforge.net/">Oscar Bundle Repository</a>. (It should also be noted that the OSGi Alliance <a href="http://www.osgi.org/Repository/HomePage">hosts a bundle repository</a>, and that some vendors of OSGi-based infrastructure also provide bundle repositories.)<br /><br />Before its revival in January, the RFC was last worked on in March, 2006. Meanwhile, the Eclipse P2 project has continued to evolve, addressing much of the same space (and more besides). The current RFC 112 draft was published as one of the <a href="http://www.osgi.org/download/osgi-4.2-early-draft3.pdf">early design drafts</a> released for EclipseCon / OSGi DevCon last month.<br /><br />One challenge the EEG faced was that no one on the EEG knew much, if anything, about what was going on with <a href="http://wiki.eclipse.org/Equinox_p2_Getting_Started">P2</a>. We understood that we needed to take the P2 work into consideration - this was clearly stated during the <a href="http://www.eclipsecon.org/2009/sessions?id=789">OSGi BOF</a> for example, in addition to other community members pointing this out. It was necessary for the EEG to get up to speed on P2, and <a href="http://www.linkedin.com/pub/7/62a/6b2">Pascal Rapicault</a> was kind enough to join the EEG calls and give us a presentation.<br /><br />What has emerged is a kind of consensus, at least on the approach to the requirements. Here I need to also mention that the normal OSGi Alliance standardization process starts with an RFP, not an RFC. OBR was an exception to this rule, and when questions started to come up about the requirements behind its design, it was necessary for the EEG to take a step back and document the requirements in an RFP we could all agree to. This is basically where we are in the process right now.<br /><br />During today's call however we got a little closer to returning to the design work. At EclipseCon we announced the schedule for the next release of the OSGi specifications - R4.2. The core is going to be published in June, the compendium in July (adding distributed OSGi and the Spring-inspired Blueprint service), and an enterprise "profile" is scheduled for Q4 (I suppose this means December, realistically) that will contain the various Java EE component mappings. The OBR standard is also targeted for the December release. To get there, as for any other part of the OSGi standard, we have to follow the OSGi Alliance process and ensure everything is approved by the membership and the Board of Directors.<br /><br />Anyway, where we are in the process is trying to gain consensus around the requirements. The debate is basically over what should be considered in scope for the standard. The most fundamental requirement is to standardize on a repository for bundles and their associated resources, so that someone searching for a particular bundle or set of bundles has a place to find and retrieve them, and in so doing resolve any dependencies they may have among each other and/or to external resources such as configuration files or data resources.<br /><br />The debate really centers around how much further to go. I think it's fair to say we reached consensus on two items: the layered approach and that the core foundation is the repository. Requirements for additional features and functions on top of the repository are not really considered optional by developers who need tools to assemble, provision, and deploy OSGi-based applications. But this additional level or levels may also not be necessary to standardize. If we do a good job with the core, vendors and open source projects can add on these other capabilities.<br /><br />One other thing we may want to tackle - and there is another RFP being written about this - is to define an application in the context of an OSGi framework. This is a controversial topic, since we want to avoid enforcing a static style of application definition onto a dynamic framework, but nonetheless seems like it would be useful to help support additional development lifecycle stages, beyond a simple retrieve & resolve.Eric Newcomerhttp://www.blogger.com/profile/06128310302941718982noreply@blogger.com2tag:blogger.com,1999:blog-5080638158547477914.post-59388613200800406152009-04-14T17:05:00.000-04:002009-04-21T16:23:56.225-04:00Questions from today's Webinar on Enterprise OSGi4/21 Update: The <a href="http://fusesource.com/resources/video-archived-webinars/">archived Webinar has been posted, and a Webinar on Distributed OSGi scheduled for April 28</a> with <a href="http://coderthoughts.blogspot.com/">David Bosschaert</a> (one of the design's authors and a developer of the RI at Apache CXF). David is also a good presenter, and I've seen an early draft of the presentation. It looks like it will be very good. <br /><br />Also a correction to one of the answers below, thanks to <a href="http://neilbartlett.name/blog/">Neil Bartlett</a> for that (and apologies for the delay posting the fix). <br /><br />Eric<br /><br />----correction---<br /><br />In this answer, I said that <a href="http://jcp.org/en/jsr/detail?id=291">JSR 291</a> makes OSGi part of Java SE. It does not. The approval of JSR 291 makes OSGi officially part of Java, but not part of Java SE. It would also need to be included in the platform JSR for Java SE for that to be the case. Sorry for the mistake, and thanks again for the correction. <br /><br />Q: I understand Java 7 includes the osgi f/w, referencing it directly. does that mean that equinox will be part of java 7 SE?<br />A: First of all, Equinox is the framework implementation, not the specification. Normally the specification is what gets included into a Java edition. But this actually brings up the overall relationship between the JCP and OSGi Alliance. OSGi was started within the JCP as JSR 8 and later the participants decided to split out into an independent activity and formed the Alliance. However, the Alliance retained the rights to evolve JSR8 (OSGi) and propose it back into the JCP, which was done for example in JSR 291, which formally incorporates OSGi R4.1 into Java SE. It's a bit hard to predict what will happen in the future, since things are not completely aligned, but JSR 294 for example is being worked on in close cooperation with the OSGi community. A larger issue exists around this space, for example the controversy over Apache Harmony and their ability to obtain TCKs for certification. Sun has apparently decided to work on Java 7 outside the JCP in the OpenJDK project, which it controls. They have also started something there called Project Jigsaw, and so far that is not good coordination between that modularization effort and the OSGi community. But Sun used OSGi in Glassfish and some other projects, and did a good job of it, too - so perhaps there will be incentive enough over time to bring everything together and ensure the right thing is done for everyone.<br /><br />----------------original answers-------------<br /><br />Here are the answers to all the questions we received during today's <a href="http://fusesource.com/resources/video-archived-webinars/">Webinar</a> on Enterprise OSGi. Thanks to everyone for attending! If anyone has more questions, post them here.<br /><br />Eric <br /> <br />Several Qs: will the slide set be made available at the end of the presentation ?<br />A: A recording of the webinar will be posted on the Progress <a href="http://fusesource.com/resources/video-archived-webinars/">FUSE Web site</a>. Those who requested a copy of the ppt during the presentation will receive a copy directly. Anyone else wishing to receive a copy directly post your email address. <br /> <br />Q: what work is being done to provide support for management tooling?<br />A: At this point the major activity is mapping JMX to the OSGi framework - this is scheduled to be part of the Java EE mapping profile published in Q4. Otherwise the OSGi framework includes its own management tooling, both command line and API, for installing bundles, starting, stopping bundles etc. <br /> <br />Q: Does Progress want to implement Blueprint based on Felix iPojo?<br />A: As an integration software supplier, Progress is unlikely to develop its own Blueprint service. However we expect that other vendors will supply an implementation of this specification in addition to SpringSource, who has already announced the intention to implement it. Other alternatives for help in developing OSGi services include OSGi <a href="http://www.aqute.biz/Snippets/HelloWorldComponent">Declarative Services</a>, <a href="http://felix.apache.org/site/ipojo-concepts-overview.html">iPOJO</a>, and <a href="http://code.google.com/p/peaberry/">Peaberry</a>.<br /><br />Q: I think that DS should also be part of Enterprise OSGi: It is on par with Spring DM!<br />A: Yes, thanks for mentioning that, the specifications certainly still include DS as an option.<br /><br />Q: Is OSGI only for Java based applications? Can it be used for web applications with java based services on the server and javascript based clients?<br />A: Yes. <a href="http://coderthoughts.blogspot.com/2009/02/distributed-osgi-powered-ajax-webapp.html">Here's an example</a>.<br /> <br />Q: Do the core enterprise revisions include work to make RMI work under OSGi frameworks?<br />A: Basically, yes. The enterprise edition does not require RMI but it is one of the supported distribution software types.<br /> <br />Q: Does the service registry have any relationship to UDDI or any other registry standard?<br />A: Basically, no. The OSGi service registry is specific to the OSGi framework. However the distributed OSGi design includes a "discovery service" that is intended to allow access to UDDI and other external registry standards such as LDAP and SLP.<br /> <br />Q: When we talk about the OSGI "registry", how does this integrate with runtime endpoint management (distinct from uddi based registries which are yet another topic)"<br />A: I'm not sure I completely understand the question, but perhaps I can explain the OSGi registry in a way that will help. Every service deployed to the OSGi framework is required to register with OSGi registry - that is how other services find it. The registry was designed for single-JVM use only - as per the previous question we have added extensions for discovering services in the remote case. The OSGi registry is therefore part of every OSGi framework deployment, but extensions were required for it to support remote service invocations using existing distribution software types.<br /> <br />Q: Can this be leveraged for RIA/Ajax web applications to discover services. Especially REST based services.<br />A: Yes, absolutely. See this <a href="http://coderthoughts.blogspot.com/2009/02/distributed-osgi-powered-ajax-webapp.html">example</a> for more information . Regarding REST specifically this is a bit of a work in progress. The background to this topic is the fact that an OSGi service interface is a Java interface today, which implies a synchronous call/return semantic, and is an easier fit with RPC-style distribution software systems. However there has been some work in the area of mapping OSGi to REST-style communication patterns and I actually think this is a better fit for the dynamic environment of an OSGi framework than a communication system that depends on persistent sessions (since a persistent session could be broken by a dynamic service deploy/undeploy operation). I think you will be seeing much more work in this area in the future. Including discovery.<br /> <br />Q: What scripting language(s) are supported?<br />A: None, directly. The OSGi specification (today at least) is specific to the Java language. However we expect some scripting & dynamic languages & DSLs capable of running in a JVM to support OSGi, for example <a href="http://www.scala-lang.org/">Scala</a> and <a href="http://groovy.codehaus.org/">Groovy</a> (which SpringSource has said they are already mapping to OSGi).<br /> <br />Q: what are the major pain points of using OSGi technology in the enterprise apps that we need to be aware of?<br />A: We have talked about some of these, such as the difficulty in migrating existing code (which typically uses different classpath assumptions) and the lack of tooling for the complete development lifecycle. However one of the biggest issues people report back from their experiences is conceptual - that using OSGi requires a different way of thinking about developing applications, and this takes some getting used to.<br /> <br />Q: Can you contrast Distributed OSGi and Jini?<br />A: Well, first of all we expect Jini to be one of the distribution software systems that will be mapped into OSGi, and there's an example already of Jini used with OSGi in the Paremus Infiniflow product. However, the EEG decided not to standardize on Jini or any other single distribution software type. So while we expect people to use Jini and OSGi together, it is not required. One key difference between Jini and the design of distributed OSGi is that distributed OSGi does not support serializing executable code (which I think is a bad idea anyway because there are some complex problems that I don't think you can really solve - but this is another discussion, I know a lot of people like to do it).<br /> <br />Q: Can we have Eric's email address?<br />A: You can post yours here and I'll reply or follow me on Twitter ("enewc") to get in touch. (I apologize but I don't like posting the address publicly due to spam.)<br /><br />Q: Will the distributed connectivity model maintain support for other service binding specifications (namely Declarative Services)?<br />A: Yes, absolutely. Anything that works with OSGi services is supported since the design extends the OSGi service model itself.<br /> <br />Q: Is remote invocation over HTTP or RMI supported?<br />A: Yes<br /><br />Q: Can the transport protocol be customized - e.g. to use ActiveMQ or other MQ?<br />A: Yes. The design specifically allows for the use of multiple protocols and data formats. One current constraint is the use of the Java interface to invoke a service, which implies a synchronous semantic to the communication. MQ systems can be used currently to implement the request/response message pattern and over time we will be working to create a design to more explicitly support asynchronous messaging.<br /> <br />Q: You mentioned that performance tests will be in place in order the check validity of the implementation. Will performance metrics be part of the upcoming spec and does an implementation have to meet those performance requirements to get certified?<br />A: Sorry about this misunderstanding - the conformance tests only test conformance to the specifications, they do not measure performance.<br /><br />Q: Will Progress make available a simple Distributed OSGi Example as a learning start point?<br />A: Yes, <a href="http://coderthoughts.blogspot.com/2009/02/distributed-osgi-simple-example.html">see this example</a>.<br /><br />Q: How does Distributed OSGI compare to SCA- Service Component Architecture?<br />A: We reused parts of SCA in the distributed OSGi design since the SCA metadata is abstract from distribution software type, and here we found the two to be very compatible. SCA defines a static component model while OSGi defines a dynamic component model, and here is where the two diverge. But SCA has been successfully mapped onto OSGi frameworks, for example the Apache Tuscany project and Paramus have done this. I expect applications developed using SCA can be deployed onto OSGi without problem - the difference becomes an issue only when using the different programming models.<br /> <br />Q: Are there benefits in using the distributed api across cores on a multi-core machine?<br />A: I have to say this is a bit of an unknown at the moment. No doubt multi-core architectures are going to have a huge impact on software systems across the board, and on enterprise designs as well, but it's too soon to try to predict how they might impact distributed OSGi (most likely this will occur through the various distribution software types mapped to distributed OSGi though).<br /><br />Q: How does the Blueprint Service/Component Model relate to the Service Component Architecture (SCA) concept?<br />A: I actually think they are similar, but the design of SCA includes more of Web services and languages other than Java. SCA is intended to be used for very large, heterogeneous SOA-style applications while the Blueprint Service is specific to the OSGi framework at the moment. Also the Blueprint Service allows explicit development of OSGi services, which SCA does not.<br /> <br />Q: isn't the Distributed OSGi some sort of IIOP/RMI mix that made EJB such a problem in the first place?<br />A: No, distributed OSGi does not define any particular distribution software type, and has nothing to do with EJBs. In fact the EEG does not include EJB mapping on the current list of Java EE components we're working on. RMI/IIOP is an example of a distribution software system that could be used with distributed OSGi, but distributed OSGi does not require it, or any other specific type of distribution software.<br /><br />Q: Given that ServiceMix wraps its OSGI runtime and allows for distributed services this way, is there still a need for a distributed OSGI standard?<br />A: The distributed OSGi standard is not intended as a replacement for an existing solutions. If you're using ServiceMix today for distributed application functionality you don't have to change anything. Distributed OSGi is intended for use with the OSGi service model, so it really only applies to developers interested in using the OSGi service programming model directly (as opposed to indirectly using OSGi through a product) to communicate with other OSGi services in other JVMs, or to external services outside of the OSGi environment. The starting point for distributed OSGi is always an OSGi service.<br /><br />Q: Which OSGi framework is being used?<br />A: Any. The OSGi specifications are defined independently of any framework implementation. We expect all of the framework implementations to implement the new versions of the specifications, perhaps not every part, and perhaps not all at the same time, but nothing we do in the EEG is specific to any framework implementation.<br /> <br />Q: Can I deploy more than one module which implements the same service interface ?<br />A: Yes.<br /> <br />Q: I heard Equinox - would this also be available as part of APache Felix?<br />A: Yes. I mentioned Equinox several times because it's the reference implementation for the core framework (including for the new R4.2 release) and therefore it will be available at the same time the specifications are published. However we have had the participation of the Apache Felix project lead (Richard Hall) in the EEG since the beginning and I expect Apache Felix to implement the new specifications as well, I just am not aware of the timing.<br /><br />Q: I understand Java 7 includes the osgi f/w, referencing it directly. does that mean that equinox will be part of java 7 SE?<br />A: First of all, Equinox is the framework implementation, not the specification. Normally the specification is what gets included into a Java edition. But this actually brings up the overall relationship between the JCP and OSGi Alliance. OSGi was started within the JCP as JSR 8 and later the participants decided to split out into an independent activity and formed the Alliance. However, the Alliance retained the rights to evolve JSR8 (OSGi) and propose it back into the JCP, which was done for example in JSR 291, which formally incorporates OSGi R4.1 into Java SE. It's a bit hard to predict what will happen in the future, since things are not completely aligned, but JSR 294 for example is being worked on in close cooperation with the OSGi community. A larger issue exists around this space, for example the controversy over Apache Harmony and their ability to obtain TCKs for certification. Sun has apparently decided to work on Java 7 outside the JCP in the OpenJDK project, which it controls. They have also started something there called Project Jigsaw, and so far that is not good coordination between that modularization effort and the OSGi community. But Sun used OSGi in Glassfish and some other projects, and did a good job of it, too - so perhaps there will be incentive enough over time to bring everything together and ensure the right thing is done for everyone.<br /> <br />Q: What about standardization? Currently one can provide a certified R4 framework with just the core features. Will there be a certification for the EE features? Are there plans to make this a JSR?<br />A: No, the plan is to rely upon existing certification for Java EE features, and develop TCKs for OSGi that apply only to the mapping part of the design. In other words, OSGi has no intention to certify Java EE APIs that already have a certification process in place.<br /><br />Q: Is there any publically available information about JMX integration? (Is that RFC 139? Is *that* available?)<br />A: Yes, it's in the <a href="http://www.osgi.org/download/osgi-4.2-early-draft3.pdf">early draft released last month</a> along with designs for JTA, JNDI, Web apps, distributed OSGi, JDBC, and the Blueprint service. <br /> <br />Q: For web/war support, is there a link to preliminary spec and is work being done on a reference implementation.<br />A: See the <a href="http://www.osgi.org/download/osgi-4.2-early-draft3.pdf">early draft</a> and yes, work is being done by EEG members on a reference implementation, which should be ready later in the year (and no later than publication of the Java EE spec in Q4).<br /><br />Q: How can I convince our operators to go the extra mile and using a much more complex deployment. Are there any benefits for them?<br />A: The main benefit for IT operations is the dynamic deployment and management of services and bundles in the OSGi framework. The benefit of using OSGi for service development and deployment is reduced downtime for maintenance updates and upgrades.<br /> <br />Q: Could Spring DM server replace Apache Felix as the OSGi container in FUSE?<br />A: The answer is no because Spring DM is not a framework - it uses Eclipse Equinox. FUSE works with both Apache Felix and Eclipse Equinox. As far as I know the Spring dm Server works only with the Equinox framework.<br /><br />Q: Do the connections between OSGi services perform better than JBI connections?<br />A: This is a little bit of an apples-to-oranges situation and difficult to answer this for sure. Local connections between OSGi services perform very well since they were designed for operation within a single JVM (i.e. no network stack, no serialization of data etc). On the other hand JBI was specifically designed for remote invocation using a normalized message router. When distributed OSGi uses JBI/NMR as a distribution software type (as is basically the<br />case in SMX/FUSE ESB) I would expect the performance to be exactly the same, or so close it would be hard to tell the difference.<br /><br />Q: Can you please post the full set of questions with answers at some point?<br />A: I'm glad you asked (whew)! Yes.Eric Newcomerhttp://www.blogger.com/profile/06128310302941718982noreply@blogger.com4tag:blogger.com,1999:blog-5080638158547477914.post-87214548308483267562009-04-09T11:05:00.001-04:002009-04-09T11:32:03.158-04:00Webinar on Enterprise OSGi Tuesday April 14I wanted to let you know about the webinars I'll be doing next Tuesday, April 14 (sponsored by <a href="http://www.progress.com/index.ssp">Progress Software</a>) on the enterprise edition of OSGi.<br /><br />I'll be going over details about the enterprise OSGi work, including the background on it, the release schedule, and what we're still working on. I'll also be giving some details on the OSGi related <a href="http://fusesource.com/">open source projects</a> that Progress Software is involved in.<br /><br />Here are the registration links (the content is the same, just the time is different, to accommodate folks in different time zones):<br /><ul><li><a href="https://progress.webex.com/progress/onstage/g.php?t=a&d=718908929&SourceId=EB">Registration for webinar at 8 am Eastern</a></li></ul><ul><li><a href="https://progress.webex.com/progress/onstage/g.php?t=a&d=712967718&SourceId=EB">Registration for webinar at 1 pm Eastern</a><br /></li></ul>If you want, you can attend both and see whether I do better first thing in the morning (!) or after lunch ;-)<br /><br />I hope you can join. I've been involved in this effort from the beginning, and it's been very interesting. We are not done, but we are getting close to a major milestone this summer. As always, I'm interested in feedback.<br /><br /><br />Partial description copied here from the registration site FYI:<br /><br />"The arrival of the new version of OSGi in mid 2009 represents an important new step for enterprise Java toward improved modularity, development efficiency, and dynamic deployment capabilities. The WebCast describes the new enterprise capabilities of the OSGi framework, highlights Progress' FUSE [open source projects], and outlines the future of what is quickly becoming the most important standard in Java today.<br /><br />The enterprise edition of the OSGi specification (R4.2) includes:<br /><br />--Enhancements to the core framework specifically designed to support enterprise application requirements<br />--A new OSGi Blueprint Service derived from the Spring Framework to simplify development of OSGi-based applications<br />--A new Distributed OSGi service that allows OSGi services to communicate with each other remotely, using multiple protocols and formats"Eric Newcomerhttp://www.blogger.com/profile/06128310302941718982noreply@blogger.com4tag:blogger.com,1999:blog-5080638158547477914.post-79572944183151612312009-04-06T20:15:00.000-04:002009-04-07T17:53:33.981-04:00OSGi spec updates, new enterprise presentation<div> </div>Apologies for the delay getting to this. A <a href="http://www.osgi.org/wiki/uploads/Links/2009_03_20_EnterpriseValuePointsFinal.pdf">presentation</a> has been posted to the <a href="http://www.osgi.org/Main/HomePage">OSGi Alliance website</a> to summarize the benefits of the enterprise release.<br /><br />Also <a href="http://www.osgi.org/Specifications/Drafts">early drafts</a> of the R4.2 specification and current design docs (RFCs) have been published, including some new RFCs and updates to some of the previously published RFCs.<br /><br />Lots of interesting presentations were given at EclipseCon / OSGi Dev Con, and summaries of them can still be found on the <a href="http://www.eclipsecon.org/2009/sessions?category=Supporting%20Technology%20-%20OSGi%20DevCon">EclipseCon site</a>. Many of the blogs listed on my blogroll contain reports on the EclipseCon activities, with <a href="http://alblue.blogspot.com/">Al Blewitt</a> in particular providing good daily summaries.Eric Newcomerhttp://www.blogger.com/profile/06128310302941718982noreply@blogger.com0tag:blogger.com,1999:blog-5080638158547477914.post-88691252510055892422009-04-02T16:03:00.000-04:002009-04-02T16:30:21.567-04:00Tooling Related Challenges for OSGi EEGDuring <a href="http://www.eclipsecon.org/2009/">EclipseCon</a> last week there was a <a href="http://www.eclipsecon.org/2009/sessions?id=787">BOF about tools for OSGi</a>, and the day after an <a href="http://www.osgi.org/Event/20090327">OSGi Tool Summit</a> (Chris Aniszczyk posted a <a href="http://eclipsesource.com/blogs/2009/03/31/osgi-tool-summit-recap/">good summary</a>).<br /><br />Two significant challenges for the <a href="http://www.osgi.org/EEG/HomePage">EEG</a> emerged from these excellent discussions: complete the <a href="http://www.osgi.org/Repository/HomePage">OBR</a> design and define the term "application" as it relates to a collection of OSGi bundles and the resources they depend on. The OBR design work was partially completed in 2006, before the EEG started, and we had initially hoped to pick up the work from where it was left off. <br /><br />At the <a href="http://www.eclipsecon.org/2009/sessions?id=789">main OSGi BOF</a> it quickly became apparent that the Eclipse/OSGi community had diverged somewhat in this area, with <a href="http://wiki.eclipse.org/Equinox/p2">Eclipse P2</a> taking a different approach. Among the attendees, <a href="http://www.sonatype.com/people/author/jason/">Jason van Zyl</a> probably put it best when he said (basically) "I don't care which one I have to follow, I just want a single standard" to support build, provisioning, and deployment lifecycle activities for OSGi. (Jason's company, <a href="http://www.sonatype.com/">Sonatype</a>, is developing Maven based tooling for OSGi application development that promises to address a lot of these challenges.)<br /><br />The challenge for <a href="http://thought-burp.blogspot.com/">Tim</a> and me will be getting the OBR and P2 folks together and hashing out something agreeable to all. Unfortunately for <a href="http://www.tensegrity.hellblazer.com/2009/03/osgi-rfp-122---the-osgi-bundle-repository.html">Hal</a>, he was the one to volunteer to drive this effort ;-) (The EEG work depends on volunteers to drive requirements and design docs.)<br /><br />To be fair, none of us in the EEG really knew much about what was going on with P2, so it's important to take a step back and essentially reset the discussion. Unfortunately, during the January EEG F2F we identified progressing OBR as the highest priority work item...and with the strident calls for address the tooling challenges, we are going to continue to strongly focus on it.<br /><br />A related topic for the EEG is the definition of an application as it relates to a deployment on an OSGi framework. A simple answer to this question is that an application is the same as a bundle, or anyway a bundle that references or includes all the other bundles it needs. But for enterprise applications, a strong requirement has been given to ensure consistency across the develop-test-deploy into production cycle. <br /><br />The dynamic nature of the OSGi framework, usually one of its most attractive benefits, can be a liability in this area. So it seems there needs to be some way to formalize some metadata for what it means for a collection of bundles and associated resources to be used for a specific application. We have just started on the requirements document for this, but this is strongly related to the bundle repository/provisioning standard - the application definition is something that could be stored in and retrieved from the repository, and used to filter the collection of bundles and resources that need to be resolved and provisioned...<br /><br />Should be fun!Eric Newcomerhttp://www.blogger.com/profile/06128310302941718982noreply@blogger.com2tag:blogger.com,1999:blog-5080638158547477914.post-18797004990983456712009-03-28T17:09:00.001-04:002009-03-30T13:36:00.961-04:00Enterprise OSGi - "Not List"I spend a lot of time talking about what enterprise OSGi is, but I always get a lot of questions, particularly about distributed OSGi. I thought it might help to put out a list of what enterprise OSGi is <span style="font-style: italic;">not</span>.<br /><br />Enterprise OSGi is <span style="font-style: italic;">not</span>:<br /><ul><li>Java EE - but EE components are being mapped to OSGi </li><li>A new distributed computing stack - but it defines how to use existing ones</li><li>Spring - but it has a "Spring-inspired" Blueprint service that does something similar<br /></li><li>Something a bunch of vendors dreamed up and decided to standardize - it's a grass roots effort started because people were already using OSGi for enterprise applications and needed help<br /></li><li>Done - the release of the specification is scheduled for June/July (part 1) and December (Part 2)</li><li>Simply a deployment standard - the real power and ultimate benefits of OSGi are in its service programming model </li><li>Untested - the OSGi Framework has been successfully used in enterprise scale deployments<br /></li></ul>Many of you who have been following the OSGi specification for a while are familiar with its trajectory - starting with its adoption as the platform for Eclipse, the OSGi Framework is used underneath most enterprise products based on Java, including market leading application servers, development tools, portals, and ESBs.<br /><br />The question that stirs the most debate is not this aspect of OSGi but whether enterprise Java application developers will embrace it in addition to, or in place of, Java EE APIs. Those of us working on the enterprise OSGi release do understand that it is currently too hard to use, and that it's best to develop OSGi bundles and services using the Spring Framework/Blueprint service or another programming abstraction technology such as <a href="http://felix.apache.org/site/ipojo-concepts-overview.html">iPOJO</a> or <a href="http://code.google.com/p/peaberry/">Peaberry</a>. But we fully expect the benefits OSGi provides for improved modularity and dynamic deployment and update are benefits enterprise developers need.Eric Newcomerhttp://www.blogger.com/profile/06128310302941718982noreply@blogger.com2tag:blogger.com,1999:blog-5080638158547477914.post-62444354171388850292009-03-25T23:38:00.000-04:002009-03-26T00:07:25.947-04:00Good information, bad conclusionKirk has written an <a href="http://java.dzone.com/news/osgi-discontent-no-migration">interesting blog post</a> about OSGi for the Enterprise. He may have done a good job at finding a controversial point to pursue, but unfortunately does not get it right. It is true there is currently no migration path, and tooling is an issue, but neither is to the point of enterprise adoption.<br /><br />I'm currently sitting in the <a href="http://www.eclipsecon.org/2009/sessions?id=787">OSGi tools BOF</a> at EclipseCon, and I can strongly validate the lack of tooling as a big issue. Kirk is pretty much on the money with his technical analysis, but the conclusion he draws is incorrect. This is a common trap people fall into when comparing a new, disruptive technology against an established, mature technology.<br /><br />I remember clearly in the late '90s when most people in the TP monitor community said that Java application servers would never be used in the enterprise. Before that the conventional wisdom in the database world was that relational database would never be fast enough for update intensive applications.<br /><br />The question is not how OSGi compares to Java EE application servers, but how it meets enterprise application requirements in its own right. If you compare a new, disruptive technology directly to a mature, established technology you cannot possibly reach the right conclusion. This phenomenon well documented in the "<a href="http://books.google.com/books?id=lqKho8KWXmAC&dq=innovator" hl="en&ei=" printsec="'frontcover&source=" sa="X&oi=" resnum="4&ct=">Innovator's Dilemma</a>" for example. It is not the technology that's important but the requirements it's designed to address.<br /><br />The enterprise is not a monolithic environment. One size does not fit all and many application requirements are better met by OSGi than Java EE, and many applications are less demanding than others. Kirk does a good job understanding and presenting OSGi technology and its benefits, but he does not ask the right questions about how well its features and functions match application requirements. The fact that something exists in the enterprise does not necessarily or predictably indicate what is needed next.<br /><br />The issue is not whether OSGi can replace Java EE application servers but whether enterprise applications, and which ones, can benefit from using OSGi. Furthermore the enterprise development process is often a long term effort, and although features may be missing today for using OSGi in some applications, many of these things will be solved soon.<br /><br />The people in this room complaining strongly about the lack of tooling are equally passionate about the benefits of OSGi, and are intent on using it to solve problems that application servers can't, and won't. They would not be here if they thought it wasn't ready.Eric Newcomerhttp://www.blogger.com/profile/06128310302941718982noreply@blogger.com4tag:blogger.com,1999:blog-5080638158547477914.post-27572099511029206582009-03-13T17:21:00.000-04:002009-03-16T11:54:58.062-04:00OSGi BOF at EclipseCon<span style="font-style: italic;">Update 3/16: Multiple OSGi BOFs at EclipseCon - Monday evening is the general OSGi BOF and Tuesday evening is the Enterprise OSGi BOF.</span><br /><br />A week from Monday (wow time flies) the OSGi BOF will be held at EclipseCon. My EEG <a href="http://thought-burp.blogspot.com/">co-chair</a> and I will be presenting <a href="https://www.eclipsecon.org/submissions/2009/view_talk.php?id=790">an overview of the upcoming 4.2 OSGi specification release</a>. The goal is to summarize the release and start a discussion. <a href="http://blog.bjhargrave.com/">BJ</a> and <a href="http://www.aqute.biz/Main/HomePage">Peter</a> are also going to be there, as are several other members of the core platform and enterprise expert groups, so this should be a good opportunity to engage the folks working to finish things up.<br /><br />As this last sentence implies, the release is not yet completed, although it is being released in stages, and the core is about done. The compendium will follow, and later this year a collection of Java EE component mappings. So there is still an opportunity for feedback and input.<br /><br />This week we also prepared another early release draft (third one) for approval by the OSGi Board, and with any luck this will be available early next week. It includes further updates to the RFCs (i.e. design docs) from which the specification updates are derived, some RFCs for Java EE mappings that haven't been previously published, and early drafts of the updated core and compendium.<br /><br />We also just completed three days of (intense!) EG meetings, and therefore will have some recent updates to share.<br /><br />Hope to see you at the 'Con! If not, please take a look at the early drafts and submit feedback.Eric Newcomerhttp://www.blogger.com/profile/06128310302941718982noreply@blogger.com0tag:blogger.com,1999:blog-5080638158547477914.post-84095814551659464632009-03-05T20:10:00.000-05:002009-03-05T17:06:51.317-05:00Modularity Reduces ComplexityIt's taken me a while to post, this apologies for that.<br /><br />The most important thing I got out of <a href="http://www.objectwatch.com/">Roger Sessions</a>' presentation at the <a href="http://ericnewcomer.wordpress.com/2009/01/18/iasa-meeting-this-week-in-boston/">January IASA NE meeting in Boston</a> is that modularity helps reduce complexity.<br /><br />I'm not sure Roger would put it that way, but I think he'd agree it's part of the solution to reducing the complexity of IT systems. I think his main message was that everyone needs to take reducing complexity into account whenever they're designing or upgrading an IT system. Just as you would design in security or usability, you'd design out complexity. So he says...<br /><br />I'm starting to think that finding the right methodology, or the approach to software development is more important than ever. Much more important than technology per se. For one thing, I think we have the basic technology we need - operating systems, languages, databases, middleware, Web servers, etc.<br /><br />For another, this often comes up in the <a href="http://www.theserverside.com/news/thread.tss?thread_id=53569">debate over enterprise OSGi</a>. A key issue around adoption of the OSGi programming model for enteprise applications appears to be the learning curve, or the mindset. Constructing applications using services is very different from using APIs, especially when the services support dynamic deployment, dynamic activation, and dynamic update.<br /><br />Modularity is not limited to the OSGi framework at all, its variations include SOA, Web services, CORBA, .NET, Java EE, Spring, and so on. The potential relationship of complexity to modularity (i.e. as in adopting modularity as a technique to reduce complexity) was therefore the most interesting part of the presentation.<br /><br />(BTW I realize this list mentions SOA and a list of technologies - typically SOA is mentioned as the approach rather than the technology. And this is correct. The most successful SOA projects I know of succeeded because of their "governance" - and I mean this in the logical sense of how people and projects are governed, not anything to do with registry or repository products. I believe the same will be true for finding industrial methods and reducing complexity through modularity.)Eric Newcomerhttp://www.blogger.com/profile/06128310302941718982noreply@blogger.com4tag:blogger.com,1999:blog-5080638158547477914.post-40583047787680156292009-02-24T09:31:00.000-05:002009-02-24T10:38:01.173-05:00Distributed OSGi DiscussionThe reaction to <a href="http://cxf.apache.org/distributed-osgi.html">Distributed OSGi</a> (aka RFC 119) has been mixed. Those involved in the OSGi community seem to like it, while Java EE folks seem to be a little cranky about it, at least if I interpret the <a href="http://www.theserverside.com/news/thread.tss?thread_id=53569">comments on the Server Side article</a> correctly.<br /><br />(A somewhat <a href="http://www.infoq.com/articles/newcomer-distributed-osgi">longer article on InfoQ</a> includes more history and perspective, but no comments yet.)<br /><br />The <a href="http://wiki.eclipse.org/Eclipse_Communication_Framework_Project">Eclipse ECF project</a> has recently released its <a href="http://eclipsesource.com/blogs/2009/02/21/rfc-119-and-ecf-part-2/">support for Distributed OSGi</a>, including the discovery service part of the design (which is not yet included in the Apache CXF code referenced above). The <a href="http://www.eclipsecon.org/2009/sessions?id=757">session on Distributed OSGi</a> at <a href="http://www.eclipsecon.org/2009/">EclipseCon</a> next month should be very interesting, given participation from both Eclipse ECF and Apache CXF communities.<br /><br />Mike Francis of Paremus confirmed in <a href="http://modualrit.blogspot.com/2009/02/distributed-osgi-tutorials.html">a comment to my previous entry</a> that they intend to implement Distributed OSGi in the future, as part of their planned move to OSGi R4.2.<br /><br />I also have heard some discussion about the <a href="http://www.eclipse.org/riena/">Eclipse Riena project</a> adopting Distributed OSGi, but no confirmation as yet. And no statement yet from the <a href="http://wso2.org/projects/carbon">WS02 Carbon</a> folks... But the RFC 119 design does seem to be gaining ground overall.<br /><br />I have received a suggestion (see comments to blog entry referenced above) to extending the design to allow developers to directly control the distribution software (i.e. avoiding the dependency on generated proxies). I don't think anything in the design prevents this today, just as I don't think anything prevents the use of RMI to serialize executable code. I have written before about the tension between <a href="http://ericnewcomer.wordpress.com/2008/07/25/abstraction-and-control-in-rest-vs-rpc/">abstraction and control</a>. Finding the right balance is not easy.<br /><br />In terms of adding this to the standard, it could definitely be a discussion topic for a potential new requirement. Given where we are in the OSGi process (which I outline in the InfoQ article referenced above), we are more focused now on refining the current design and updating the spec than thinking about new requirements.<br /><br />I have noticed that the Eclipse ECF implementation does add some features and functions to the design, which I think is a good sign. A good standard does not define all possible features and functions, but only those necessary for compatbility across multiple projects/products -- a common foundation on which to build good, interoperable solutions. So far it looks to me like we are on the right road.Eric Newcomerhttp://www.blogger.com/profile/06128310302941718982noreply@blogger.com0tag:blogger.com,1999:blog-5080638158547477914.post-7410807615551521522009-02-09T14:23:00.001-05:002009-02-09T16:02:08.814-05:00Distributed OSGi Tutorials<a href="http://www.linkedin.com/pub/1/480/885">David Bosschaert</a>, Progress Fellow and one of the drivers behind the Distributed OSGi/RFC 119 design and implementation, has posted a couple of good tutorials about it on his blog.<br /><br />Here's his <a href="http://coderthoughts.blogspot.com/2009/02/distributed-osgi-simple-example.html">simple example</a> to get started using the <a href="http://cwiki.apache.org/confluence/display/CXF/Distributed+OSGi">Distributed OSGi Reference Implementation</a> and a more complex example using an <a href="http://coderthoughts.blogspot.com/2009/02/distributed-osgi-powered-ajax-webapp.html">Ajax client</a> for a service invocation from an external source.<br /><br />When we initially wrote the requirements for Distributed OSGi to start the <a href="http://www.osgi.org/EEG/HomePage">EEG process</a> of designing a solution that could be included in the next rev of the <a href="http://www.osgi.org/Specifications/HomePage">OSGi Specifications</a>, we focused not only on the use case in which an OSGi service is able to invoke another OSGi service in a different (potentially remote) JVM, but also on the use cases in which an OSGi service might be invoked by an object external to an OSGi Framework.<br /><br />David will be at the <a href="http://www.osgi.org/DevCon2009/HomePage">OSGi Dev Con</a> in March (co-located with <a href="http://www.eclipsecon.org/2009/">EclipseCon</a>) and will be giving a <a href="http://www.eclipsecon.org/2009/sessions?id=757">presentation and demo about Distributed OSGi/RFC 119</a> along with Scott Lewis and others. <a href="http://www.eclipse.org/ecf/">ECF</a> <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=249240">will be supporting Distributed OSGi/RFC 119</a>, and there's note to the bottom of <a href="http://wiki.eclipse.org/Comments_on_the_Riena_Project_Goals_and_Relationship_to_ECF_project">this page</a> (and a <a href="http://modualrit.blogspot.com/2009/01/check-out-distributed-osgi-ri-at-apache.html">comment to a previous post</a>) that seem to indicate that <a href="http://www.eclipse.org/riena/">Eclipse Riena</a> also will, and apparently <a href="http://www.paremus.com/products/products.html">Paremus InfiniFlow</a> too (if I have understood <a href="http://www.jroller.com/ouertani/entry/interview_paremus_sca_with_osgi">this interview</a> correctly). So it looks like we are well on our way toward our goal of completing this work during the next few months.<br /><br />In any case, please be sure to take a look and let us know what you think of Distributed OSGi/RFC 119, either in response to the blog posts or in person at OSGi Con.Eric Newcomerhttp://www.blogger.com/profile/06128310302941718982noreply@blogger.com8tag:blogger.com,1999:blog-5080638158547477914.post-43635207172170535002009-01-30T09:30:00.000-05:002009-01-30T09:53:17.014-05:00Check Out Distributed OSGi RI at Apache CXFAs I've mentioned <a href="http://blogs.iona.com/newcomer/archives/000569.html">before</a>, we've been working on the reference implementation of Distributed OSGi for a while, part of RFC 119 included in the OSGi 4.2 <a href="http://www.osgi.org/download/osgi-4.2-early-draft2.pdf">early release draft</a> (starting page 196 of the pdf), giving the initial demos at the OSGi Alliance <a href="http://www.osgi.org/CommunityEvent2008/HomePage?from=CommunityEvent.HomePage">Community Event last June</a>.<br /><br />Since then the design has changed a bit but not significantly, and RFC 119 has passed the EG vote to become part of the formal specification (it will be in the updated Compendium when it comes out later this year - <a href="http://www.osgi.org/Specifications/HomePage">see current specs here</a>).<br /><br />I'm very pleased to say the RI has now officially become a subproject to <a href="http://cxf.apache.org/">Apache CXF</a>, and you can <a href="http://svn.apache.org/repos/asf/cxf/dosgi/trunk/">find the current code at the Apache site</a>. David Bosschaert has also <a href="http://cwiki.apache.org/confluence/display/CXF/Distributed+OSGi">written up some documentation</a> about it. As always, feedback and comments are very welcome.<br /><br />A lot of information about the upcoming 4.2 release will be available at <a href="http://www.osgi.org/DevCon2009/HomePage">OSGi Dev Con</a>, co-located with EclipseCon, including more detail about Distributed OSGi and the other enterprise features.<br /><br />I should also mention that RFC 119 actually contains more than just the plain Distributed OSGi design. It also includes a discovery service design, and information about how SCA metadata can be used to configure multiple types of distribution software (this is needed since Distributed OSGi does not define distribution software, but rather how to configure existing distribution software, such as CXF, within the OSGi framework, and the design allows multiple distribution software types). RIs for these other parts of RFC 119 are also underway and should be available soon.<br /><br />I'm very happy about this one, of course, since it is the one that I and my colleagues at IONA/Progress have been working on for almost two years, with excellent collaboration from folks from Siemens, Tibco, and IBM. Not to mention the help of the entire enterprise EG!Eric Newcomerhttp://www.blogger.com/profile/06128310302941718982noreply@blogger.com2tag:blogger.com,1999:blog-5080638158547477914.post-58094336274851481582009-01-18T12:40:00.000-05:002009-01-19T18:01:01.946-05:00Making the OSGi Sausage (Nitrate Free)<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0lgg5mOc6sGO6ZtyAf5jMa1qQ_V2xoEDET1XtG84TYhivQb5MRtNsVzGNBGanSC5X6subQHzWtfGeUXYO2dc02PizRtTjNueU2-OznGvTRM1L4lMugEVLx_M6M_C6WiUhySp7FPSgkQ/s1600-h/OSGiJan_1.JPG"><img id="BLOGGER_PHOTO_ID_5292695188563001970" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 320px; CURSOR: hand; HEIGHT: 240px" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj0lgg5mOc6sGO6ZtyAf5jMa1qQ_V2xoEDET1XtG84TYhivQb5MRtNsVzGNBGanSC5X6subQHzWtfGeUXYO2dc02PizRtTjNueU2-OznGvTRM1L4lMugEVLx_M6M_C6WiUhySp7FPSgkQ/s320/OSGiJan_1.JPG" border="0" /></a>Last week <a href="http://www.progress.com/index.ssp">Progress Software</a> hosted <a href="http://www.osgi.org/WG/HomePage">OSGi expert group</a> face to face meetings - one day for <a href="http://www.osgi.org/CPEG/HomePage">CPEG</a> and one and a half days for <a href="http://www.osgi.org/EEG/HomePage">EEG</a>. Aside from complaints about the cold weather (as in why anyone in their right mind would schedule such a thing in January for the Boston area), we had a very good two and a half days, and a couple of nice dinners. Tuesday night we ate at the <a href="http://www.flatbreadcompany.com/">Flatbread Company</a> in Bedford, where we got pizza with <a href="http://www.flatbreadcompany.com/2007Menu.htm">nitrate-free pepperoni</a>.<br /><div></div><br /><div></div>This photo shows us hard at work (!) reviewing one of the many documents in process for the <a href="http://www.osgi.org/Download/File?url=/download/osgi-4.2-early-draft2.pdf">upcoming 4.2 release</a> of the <a href="http://www.osgi.org/Specifications/HomePage">OSGi specifications</a>.<br /><br />The highlights of the meeting included <a href="http://www.doc.ic.ac.uk/~abuckley/">Alex Buckley</a> joining to discuss <a href="http://jcp.org/en/jsr/detail?id=294">JSR 294</a>, which has been recently reactivated. Unfortunately, he faced a difficult task in explaining to this group why JSR 294 had not based their work on the OSGi specificiations. Alex offered two answers: the first was about the benefits of aligning design time and runtime modularity, and the second was about the preference to include metadata about modularity directly in the language rather than in an external source.<br /><br />We could only allocate about 90 minutes or so to this discussion, since we had a lot of other items to cover, so we were really only able to start the discussion. Alex was invited in the spirit of cooperation, and what I expect out if it is a definition of how the OSGi framework and JSR 294 can leverage each other. However, we will need more time to get to the bottom of this. IBM and Oracle are on the JSR 294 expert group, and with Alex's participation in the OSGi EGs, there should be good opportunities to continue the discussion in both forums.<br /><br />On the basic work of the OSGi EGs, the theme is now getting things ready for the release. Several of the design documents have been voted on, meaning <a href="http://www.aqute.biz/Main/HomePage">Peter Kriens</a> can start updating the specifications to include them. As you may know if you have read the current OSGi Specifications, they are divided between the core specification and the compendium specification. The work of CPEG is basically aimed at updating the core, and the work of EEG basically aimed at updating the compendium. It's never exactly that simple, of course, but that's the main idea.<br /><br />As usual, I'm going to focus my report on the EEG portion of the meeting. The major docs to pass EEG vote were distributed OSGi and the Spring-inspired blueprint component model. The JMX and JTA mappings also passed, but at least for JTA there's a relationship with JDBC and JPA as yet to be completed since the JDBC and JPA design docs are still in progress.<br /><br />Another highlight of the EEG meeting was the discussion focused on evaluating what our work adds up to for enterprise developers. What kinds of applications can they create? What is the enterprise release good for, and what is it not good for? What are the gaps in our work, especially those that can be filled quickly (i.e. for this release).<br /><br />As you may recall, if you have been following the EEG work, we are focusing now on which parts of Java EE make most sense to map to the OSGi framework. It seems that with Web apps, JTA, JDBC, JNDI, JPA, and JMX (although this is more precisely Java SE), distributed OSGi and Spring/Blueprint, we are in pretty good shape for meeting the requirements of most enterprise applications we could bring to mind. One important gap is JAAS, and so we will begin working to add that, too.<br /><br />A large part of the discussion focused on issues that enterprise developers encounter when starting to incorporate OSGi bundles/services into their applications. First of all, what is an application? Unlike Java EE, where you can find the definition in an external file, the OSGi framework is dynamic, and the practical definition of an application therefore becomes whatever bundles are loaded at the time. In other words, the application is more or less self-describing.<br /><br />But this isn't very helpful to someone who wants to figure out which bundles are in which "business applications" and how to build and maintain that application. I understand the resistance among OSGi folks to import a traditional static definition of such a thing, but on the other hand the world of OSGi software and existing Java code has to be integrated somehow. This is of course a lot of what SpringSource has been doing with its <a href="http://www.springsource.com/products/suite/dmserver">dm Server</a> product - adapting existing Java code so it can be successfully used in OSGi projects.<br /><br />Now let's take a step back for a moment, because the reasons to invest in OSGi based development need to be clear and of sufficient value to justify the effort. The two major benefits are modularity and dynamic deployment, which includes the ability to update an application without taking it down (there I go, using that word "application" again). The benefit of moduality is basically a development time benefit and can be achieved without a lot of recoding - although if one wants to support multiple deployment options (i.e. on an OSGi framework and also on Tomcat, an application server, or a proprietary container), then it gets more complicated.<br /><br />But to obtain the ultimate benefit of 100% uptime, to deploy and update an application without having to cycle the container, you have to invest in making all modules into OSGi services. And here we start getting into the kinds of <a href="http://peterrietzler.blogspot.com/2008/12/is-osgi-going-to-become-next-ejb-bubble.html">issues that Peter Rietzler</a> and others have been blogging about lately. This inevitably brings up the question of "green field" applications, i.e. to what extent enterprise applications are likely to be coded completely from scratch (as opposed to having to use existing code).<br /><br />Listening to the discussion, including <a href="http://www.linkedin.com/in/yan">Yan Pujante's</a> summary of his <a href="http://blog.linkedin.com/2008/06/23/osgi-at-linkedin-integrating-spring-dm-part-1/">experiences at LinkedIn</a>, I became convinced that green field applications in the enterprise space are going to be highly unlikely. In other words, we are definitely going to have to deal with the compatibility issue - otherwise the adoption barrier would just be too high. I mean, you could argue (as I did) that the benefits of adopting OSGi services are so significant as to justify a rewrite, but the more I think about it, the less likely it seems to me that enterprises are in a position to do so.<br /><br />Given this, it seems like we'll need a good sample application to illustrate how it's done, especially how it should be done, and how using an OSGi framework is different from using a Java EE container, or subset thereof. And it's probably even more important to describe how best to do it than it is to simply show the example.<br /><br />Something that enterprise developers would also probably find helpful is the bundle repository, something along the lines of <a href="http://oscar-osgi.sourceforge.net/">Oscar</a> or the Spring dm Seerver's bundle <a href="http://www.springsource.com/products/suite/repository">repository</a>. And BTW in general the SpringSource guys have done a lot of work to address the issues enterprise Java developers encounter when using OSGi.<br /><br />An effort also was made to standardize the bundle repository capabilty, and the OSGi Alliance continues to discuss the possibility of hosting one (Peter Kriens and <a href="https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/10954">Frank Mittag</a> are pushing for it) but work on the design doc was suspended a couple of years ago, more or less for lack of interest (this is how we do things at the OSGi Alliance, we rely on someone taking sufficient interest to put in some time and effort on something ;-).<br /><br />Having a bundle repository available though would not only allow developers to search for needed bundles, but also provide support for provisioning bundles and automating several other deployment related capabilities. So we decided to try to pick this work back up and try to get something done for the next release.<br /><br />One last comment relates to tooling. It isn't really in the EEG scope, but Peter Kriens said he would try to organize a joint meeting with some folks from the Eclipse Foundation, perhaps during <a href="http://www.eclipsecon.org/2009/">EclipseCon</a> (which is co-located with <a href="http://www.osgi.org/DevCon2009/HomePage">OSGi Dev Con</a>) to talk about it. Bits and pieces of tooling for OSGi exists, but nothing comprehensive yet for enterprise developers. This would also help, of course.<br /><br /><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEinDoQf9pO_EEm6ZsBCrilZyZqRHArLltCAO9L5UsrbdCyAxPVJMqYBtzVnMWZKIVNDhRqf76zD2IQWbhyaS2Vnm8irBvKaqDcWCxgmkHdQ-073vKhEIpR73bVJspV98QrW-fUkM5nopw/s1600-h/Snow09_17.JPG"><img id="BLOGGER_PHOTO_ID_5293138668035411778" style="FLOAT: right; MARGIN: 0px 0px 10px 10px; WIDTH: 213px; CURSOR: hand; HEIGHT: 320px" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEinDoQf9pO_EEm6ZsBCrilZyZqRHArLltCAO9L5UsrbdCyAxPVJMqYBtzVnMWZKIVNDhRqf76zD2IQWbhyaS2Vnm8irBvKaqDcWCxgmkHdQ-073vKhEIpR73bVJspV98QrW-fUkM5nopw/s320/Snow09_17.JPG" border="0" /></a> And just to wrap up - everyone got out of Boston just in time. The morning after the meeting ended we had -13F (-25C) on the outdoor thermometer in our kitchen. And the same the next morning. And then over the weekend, several inches of snow. But I conveniently left the grill out on the deck, just to remind myself that someday, yes, once again we will be out there using it to cook something tasty, and warm. <br /><br />See you next time.Eric Newcomerhttp://www.blogger.com/profile/06128310302941718982noreply@blogger.com0