February 23 - Keynote titled OSGi in the Enterprise: Agility, Modularity, and Architecture’s Paradox
March 22 - 25 - Tutorial on Modular Architecture
June 14 - 17 - Sessions titled Turtles and Architecture and Patterns of Modular Architecture
July 26 - 30 - Two sessions on rich mobile applications and one on agile development. Half day tutorial on software process improvement.
Right on. I just won a Best Buy drawing worth $1000. Either that or I won a shiny new virus by clicking the link. Hmm...what to do. 2012-08-29
The opinions expressed on this site are my own, and not necessarily those of my employer.
Like last year, in my Agile Architecture - Technologies and Patterns session at SpringOne2GX, I asked the attendees the same three questions surrounding class, package, and module design. This year, I had roughly 80 folks attend the session, and here is the rough breakdown of the hands shown after each of the questions.
These are consistent responses to what I see elsewhere, as well. I was hopeful that since I was attending the Spring conference, a few more developers were leveraging OSGi and actually spending some time on module design. But that doesn’t look to be the case. Maybe modularity isn’t sexy enough? I suppose that’s just a bit more fodder for the argument that there is no migration path for modularity, and that we need better tools, tutorials, and educational materials to help us design modular software. Fact is, I had more than one person stop to ask me where they can find more information. And that’s why recently, I’ve been focusing my talks on what we can do today, right now, to design more modular software.
I know we’ll be there someday. After my OOPSLA tutorial this week, Alex Buckley stopped by and we chatted for a while on modularity in JDK 7. Whether it’s Jigsaw, OSGi, or both, we can’t be sure. But one thing is certain - modularity is coming to the Java platform, and while it might not be all that cool and exciting right now, it’s going to play a significant role in how we architect and design applications going forward.
Update (10/23/09): There’s been some interest by folks in seeing the details for the free form questions (Question #5 and Question #10). Here’s the raw data, exported directly from the survey. These are each PDF documents.
I’ve also opened sharing of the survey, so you can see first-hand the survey results.
Last week, I opened the 2nd Annual OSGi Survey. The survey concluded early Tuesday, with more than 250 developers taking the survey (last year, 64 took the survey). The survey was not scientific, and it was clear that the majority of folks taking the survey were already using OSGi. But the results were interesting nonetheless, and offers some insight to how OSGi is perceived and used. Here are the results!
Let’s analyze the results, question by question. Then, we’ll offer up some analysis, with possibly more to come later. If you’re interested in last year’s results, I posted a summary of the results on my site with some detail on the APS Burton Group blog.
Question #1 - Are you familiar with the OSGi Service Platform?
92% (241) have heard of OSGi, as compared to 89.1% (57) last year.
Question #2 - Are you currently developing systems to be deployed to an OSGi runtime?
70.9% (185) were using OSGi as compared to 50% (32) last year.
Question #3 - Do you have plans to develop systems that are to be deployed to an OSGi runtime within the next 6 – 12 months?
82.7% (215) are planning to use it in the next 6 - 12 months as compared to 79.7% (51) last year.
Question #4 - Are you familiar with the available OSGi products and services?
83.5% (217) were familar with OSGi products and services as compared to 67.2% (43) last year.
Question #5 - Which OSGi implementations are you currently using or evaluating?
This was a freeform question, and in both categories (Using and Evaluating), Equinox was the clear leader, garnering more than 100 responses, with Felix coming in second. Other notables mentioned include dm Server, ProSyst mBedded Server, and Paremus Service Fabric.
Question #6 - Which of the following types of systems are you planning to deploy within an OSGi runtime?
Respondents were able to select more than one answer, resulting in a total that exceeds the number of folks taking the survey. So it’s obvious we are leveraging OSGi for different types of applications (click image for summary). In total 64.8% (162) (65.1% last year) said they were developing web apps, 17.2% (41) (11.1 % last year) were using it for embedded development, 15.6% (39) (12.7% last year) on mobile development, 50.4% (126) (39.7% last year) for rich clients, and 13.6% (34) (17.5% last year) said they weren’t using OSGi at all.
Question # 7 - What are the benefits you hope to achieve using OSGi?
Again, respondents were able to select more than one answer for this question (click image for summary). In total, 83.9% (214) (82.5% last year) wanted greater modularity, 56.6% (144) (63.5% last year) wanted hot deployment, 51.4% (131) (54% last year) wanted a more manageable runtime environment, 68.6% (175) (71.4% from last year) wanted better dependency management, 57.3% (146) (63.5% from last year) wanted bundle versioning, 63.5% (162) (65.1% last year) wanted a plugin architecture, while 10.2% (26) (14.3% from last year) abstained.
Question #8 - What are your greatest technical challenges in using OSGi?
The clear challenge in using OSGi (click image for summary), cited by 63.8% (157) (63.5% last year) of respondents, is how to use OSGi most effectively. Following a rather distant second place at 40.2% (99) (38.1% last year) was finding valid OSGi bundles. It tailed off pretty sharply after that with testing at 30.9% (76) (19% last year), debugging at 22.4% (55) (25.4% last year), and the remaining coming in each close to 11%. These were each down from last year.
Question #9 - If your application server provided an OSGi runtime container, would you consider deploying your software as modules/bundles?
87.5% (223) (88.7% last year) said they would deploy their software as modules if their platform supported it. 8.2% (21) (9.75% last year) said no they would not. 4.3% (11) (1.6% last year) said the weren’t sure what an OSGi bundle was. In total, 7 people skipped the question.
Question #10 - What obstacles must OSGi overcome to achieve widespread adoption within the enterprise?
Since this was a free form text entry field, I took the liberty of classifying the various responses. While not everyone chose to offer input, for those who did, the following obstacles were cited by the respondents as being most significant:
There were myriad other responses, as well. Some stated that complexity was an obstacle, which Hal Hildebrand refers to as the “cognitive burden” of OSGi. Another respondent pointed out that the availability of an OSGi-based “killer application” that wasn’t an IDE would also increase the visibility of OSGi. Yet another respondent pointed out that OSGi is an over-engineered solution that actually causes more problems (due to its complexity) than it solves.
What might be most interesting is that there is little significant difference from last year’s results. The results hover around the same numbers as last year, with only Question #2 and Question #4 seeing the most significance differences. There were a few aspects of the survey that struck me as particularly interesting. Tooling, a migration path, and educational material surrounding how to use OSGi most effectively continues to be a significant issue for developers, even though roughly 15% more of this year’s respondents claimed familiarity with OSGi products and tools. In other words, they’re familiar with the technology, but still recognize the need for better tools, etc. Clearly this is supported given the responses to Question #8, where the greatest challenge in using OSGi is understanding how to use it most effectively.
Last year, 50% said they were using OSGi while close to 80% said they planned to use it in the next 6 - 12 months. The response to Question #2 indicates we saw a 20% growth in adoption…somewhat close to the 30% indicated.
Developers again indicated that they want their application platforms to expose OSGi for building web applications, with almost 90% saying they’d develop web applications today using OSGi if the platform allowed them too.
Finally, the majority of folks currently using or evaluating OSGi are doing so at the framework level, not the platform level. Given that most people are planning to develop web applications using OSGi, I really would have thought that platform use and evaluation (such as dm Server or Infiniflow) would have been higher. It’s possible the way I worded Question #5 influenced how respondents answered the question.
Platform support for OSGi is coming. Well, at the very least, platform support for modularity is coming. However, once the platform does support modularity, and a rich suite of tools is available, there is still the nasty little problem surrounding how we effectively design modular software. It appears we’re on the right track, but we still have a ways to go.
Calling all Java Developers, please take the 2nd Annual OSGi Survey!
Last year, I conducted a survey to gauge industry acceptance, adoption, and understanding of OSGi. I posted a summary of the results on my site with more detail on the APS Burton Group blog. With SpringOne2GX approaching in less than one week, I decided to offer the same survey to get a feel where OSGi has gone over the past year. I contemplated changing a few of the questions to reflect what I thought would be more relevant this year, but decided against it because I really wanted an apples-to-apples comparison. The survey certainly isn’t scientific, but it’ll sure offer some decent (and maybe even interesting) insight to the OSGi market.
The Survey consists of 10 simple questions, and should take only a few minutes of your time. So if you’re involved with development on the Java platform, and can spare a few moments, your time would be greatly appreciated. I plan to stop collecting responses on Monday, October 19th, and hope to share the results in my session at SpringOne2GX next week titled Agile Architecture - Technologies and Patterns, as well as sharing the details in a blog post.
Update: Please note the DZone link that was submitted states the survey will close on Monday, Nov. 20th. That’s incorrect. The survey will close on Monday, October 19th.
There are certain paradoxes that create conflict when designing software systems. The paradoxes result in opposing forces that are counterintuitive, and require further examination to more fully understand how the tension can be resolved. Here, I explore the tension between use and reuse. Certainly there are others, too. What software development paradoxes have you encountered?
I have a simple question. What’s the difference between “use” and “reuse”? Dirk Riehle broaches the subject in suggesting that using a component is when you embed that component in a collective work and reusing a component is when you create a derivative of that component. I use the term “component” above, but it could just as easily be replaced by “method”, “object”, “module”, “service”, or anything else that you want to use. Or should I say reuse? Funny!
The topic can be quite confusing. For instance, is invoking a once deployed service from multiple consumers use or reuse? And how does this differ from including a component in multiple services? Which is use and which is reuse? The differences between these two scenarios can be seen in the diagram at right (click to enlarge).
Instead of trying to distinguish between reuse and use, let’s consider an alternative perspective. If we adopt a canonical definition of reuse, we can state that it means to simply “leverage an existing asset”. Now, let’s define use as “the ability to leverage an asset”. If we’re willing to accept these definitions, then the relationship is opposing - as one goes up, the other goes down. A module or service might be highly reusable, but very difficult to use. Likewise, a module or service might be very easy to use, but difficult to reuse. And it’s incredibly difficult to offer both.
If we make a software entity highly reusable then it’s likely a lightweight and fine-grained entity. This allows for environmental configuration driven by context and extensibility through well-defined interfaces and extension points. But with this flexibility is additional complexity that makes the entity inherently more difficult to use (flexibility and complexity are another paradox?). I explore these ideas further in Reuse: Is the Dream Dead, and draw the conclusion that
Maximizing reuse complicates use.
Understanding the forces at play here is important because they are consequential to architecture, and resolving the tension is an aspect of architectural agility. It’s virtually impossible to design a reusable software entity until we have a better understanding of it’s usage scenarios (I recall a “rule of 3″, but can’t seem to place it. Anyone know?). And since the unit of reuse is the unit of release, it figures that modularity plays a prominent role here.
Understanding principles, patterns and practices (like SOLID and modularity patterns) that increase architectural agility help resolve the tension between use and reuse, and are certainly a step in the right direction. But so too is understanding that certain decisions must be deferred until we have the requisite knowledge to make the most informed decision possible. Because of this, we should strive to minimize the architectural significance (impact and cost) of change by making our designs as reversible as possible. Reversibility doesn’t always mean great flexibility, though. Sometimes it means we make something as simple as possible so that it’s easy to change later. Either way, it’s imperative to accommodate the natural shifts that occur throughout development, and modularity plays a central role in making this happen.
For those that follow this blog, you’ll know it’s not the first time I’ve written about this topic. For others, if you’re clicking on any of the links in this post, you’re quickly discovering that, as well. Going forward, I intend to explore many of these concepts using some concrete examples that should offer a bit more insight to the discussions. I’ve put together some sample exercises for some upcoming conferences, and I intend to walk through those samples in a series of future posts. The result will be roughly seven or eight separate posts that show the evolution of a system. There’ll be code, builds, tests, and of course, modularity. Along with a lot of other stuff, too.
For now, if you’re interested in this topic, as well as ways to increase architectural agility, you might consider checking out some of my following entries (some of which are linked to above) related to this topic. You can bet there will be more coming, too!
For those of you interested in Lean and Kanban, but not much knowledge yet, it can be tough filter the noise and find information explaining what they are and how they might be different from what you’re already doing (agile, Scrum, etc.). Since top 10 lists are rather passé, I’ve gone the whole nine yards and scoured the blogosphere to come up with the best nine posts I could find that capture the essence of Lean and Kanban.
The list is in no particular order, and there’s no doubt that I’ve missed some great posts that offer insight. The blogosphere is a pretty big place, after all. Naturally, I’ve cheated a bit by pointing to related posts from within the top nine. Enjoy!
If you’re interested in learning more about Kanban, consider joining the Kanban Development Yahoo Group. Additionally, the Limited WIP Society is the home of Kanban Development, and contains some good definitions of what Kanban means within software development. And of course, the best place to learn more about Lean is to start with the Poppendiecks.
Note: Graphic courtesy of InfoQ. Used without permission.