I’ve published a summary of the OSGi survey results on the APS blog at Burton Group. Definitely some interesting numbers. The highlights? 80% said they’ll be developing software using OSGi in the next 6 - 12 months, and almost 90% said they would today if their application server supported OSGi. Those are some convincing numbers! The biggest hurdle to OSGi adoption within the enterprise? No surprise here - better enterprise vendor support, integrated toolsets, and more OSGi resources to help understand the benefits and usage patterns.

There are more details to the survey that I’ve yet to explore, and I’ll try to share with everyone what I find after further crunching the numbers

If you haven’t taken the time to fill out the OSGi survey yet, I have to encourage you to do so. The survey will remain live until June 13th. Your feedback and help is greatly appreciated, and I hope to publish the results sometime in June or July

I’ve created a simple on-line survey to gauge interest in OSGi within the enterprise. I appreciate anyone who can spare a few moments to provide their input. I plan to leave the survey open until May 30th, 2008. At some point, I hope to share the results.

It’s time to move on and show the simple elegance Spring brings to OSGi development using the HelloWorldSpec sample from the OSGi & Modularity post. But first, a little primer on Spring Dynamic Modules. Spring DM is not an OSGi implementation. Instead, Spring DM aims to make working with OSGi easier just as Spring makes the world of Enterprise Java simpler. One of the more striking characteristics of Spring DM is that it removes most your code’s dependencies on OSGi by taking care of the OSGi plumbing. To function in an OSGi runtime environment, the Spring .jars have been packaged as OSGi bundles.

Read more

The .jar file has always been a great unit of modularity on the Java platform. Unfortunately, it also comes with the classpath baggage, and .jar files were never treated as first class components. OSGi is the next generation component platform that will bring greater modularity to the Java platform. In my previous blog, I showed the simplest OSGi components imaginable. Now I want to expand on that slightly by introducing a third component that exposes a key architectural and design benefit enabled by OSGi.

Read more

Lately, I’ve been experimenting more with OSGi, and I want to share some of the examples I’ve put together. The examples involve Felix, Spring Dynamic Modules, and Jetty, though could easily be used with Equinox. Once I’m finished with these exercises, I’m hoping to compare and contrast the different approaches I’ve taken, as well as comparing embedded Jetty with the Equinox Servlet Bridge. I’m a believer that OSGi is a disruptive technology that stands to transform Java development as we know it today.

Read more

I saw the news item on InfoQ regarding MicroSoft Oslo. There was quite a bit marketing mumbo jumbo surrounding Oslo, SOA, BPM, composite applications and MDD, and not a lot of it resonated with me all that much. However, one quote did stand out.

We want to send the model to the server not the printer.

This got me thinking about Big Software in general, even if it isn’t about SOA, BPM, and a lot of other standard industry buzzwords. Developing large enterprise systems comes with a lot of baggage that smaller development efforts don’t have, and a larger codebase is part of it. There are a lot of techniques that teams apply in attempts to architect, maintain and downright understand large software systems. In fact, the problem understanding Big Software is one of the compelling forces that led me to create JarAnalyzer. Since no one person can understand all detailed aspects of a large system, give people high level visual insight into the component relationships and let them drill down from that point. Unfortunately, there is no “drill down” capability in JarAnalyzer - you only get the .jar relationships and a few metrics. But combine it with tools like JDepend, and UMLGraph and you can get a few different views. Either way, there are quite a few different techniques that can be used when it comes to dealing with large codebases. But it seems like most approaches have serious holes.

• UML Modeling. UML Modeling is typically associated with Big Design Up-Front. While I don’t agree with detailed design up-front, establishing some idea of how you want to approach design is a good idea. I don’t like designing individual use cases, but do find value in modeling application frameworks, for example. There are a few advantages in doing this. The entire development team understands the general direction. Nothing is ever set in stone, so if something changes, it also serves as a vehicle for communication. Creating a design model also offers you the opportunity to structure the model in a way that best fits your team and how developers will want to interact with and navigate the model. Unfortunately, the greatest problem with modeling is that keeping your model in sync with the source code is impossible, and most reverse engineering solutions suck. So, any modeling done needs to be at a sufficiently high enough level of abstraction such that detailed change doesn’t impact it, or the models must be short-lived, serve their immediate purpose, and then get filed in the trash bin. Generally, I like to do a bit of modeling early, followed by TDD to drive out the details of my designs.
• Post-Construction Software Visualization. Quite a few static structural analysis tools generate some form of diagram. JarAnalyzer, JDepend, and UMLGraph are examples. Some exist for the .Net platform, too. The obvious advantage is that you get an up-to-date accurate snapshot of your software system. That’s valuable. Unfortunately, the diagrams aren’t always laid out to give you the view into the system that you’d like. Tools like GraphViz do a great job laying out the diagram, but a diagram is just a single view into a system, and possibly not the view I’m looking for. They aren’t complete models, and since the output of these tools are usually images, they typically aren’t navigable. Static structure analysis is only half the battle…maybe less. Understanding class, package, and component relationships is important, but with frameworks like Spring, it’s virtually impossible to get a feel for run-time structure and behavior. Two packages might have no structural dependency between the two, but the placement of abstractions could result in a run-time relationship. I know of no tool that does a good job analyzing the run-time structure.
• Metrics. Many static analysis tools generate metrics and other type of feedback that provide insight into code quality. Most of these don’t necessarily help you understand a system better, but they can help you create a system that is more easily understandable. I like metrics to help guide refactoring, because the design as it’s manifest in code is not always the design as it’s envisioned in the mind of the developer. Metrics offer objective advice on the quality of your application that should be used subjectively. A great resource for analysis tools for Java/JEE development is java-source.net.
• DSM matrices. I haven’t done much work with Dependency (aka. Design) Structure Matrices, but I intend to explore. I’ve talked to a few co-workers who have found them useful.
• MDD. Model-Driven-Development has been thrown around the industry for a while. If anyone has actually had any great deal of success developing Big Software using MDD, I’d love to hear about it. I’m very skeptical.

If I had the perfect solution, it would be real-time visualization of the source, be it static or dynamic, with the ability to create different views of the system. I’d be able to start high-level, with either .jar or package relationships. Then drill down into the .jar and packages to view details. But I’d easily be able to filter out information that I didn’t want to see. For instance, I might want to see the class diagram for a particular package, but in a different diagram I might want to see the class diagram for only those classes that span packages while suppressing classes that have relationships only to other classes in a package. I’d like to capture the behavior of a running system as a sequence diagram, and I’d like to double-click on any class or object and view the source. It’d be perfect if all this would integrate with my Spring configuration files, so I can build that into a view of the system, too. Of course, I want my metrics. I’d like an API available so that I could write unit tests that validate my design. And most important, if I have all of this coolness, I want the ability to filter out the noise. Essentially, I’d like to combine the navigability and view aspects of modelling with the accuracy of post-construction visualization. I need to make sure my models are accurate, but I also want different views into the system depending on what I’m looking for. And I’d like this wonderful tool available as an Eclipse plug-in, standalone IDE, and Ant task. I want all of this, and I want it to perform well, too. Vendors might claim their tool does this for me, but I know it doesn’t.

What’s your wishlist?

For years, OSGi technology has flourished in the embedded systems and networked devices market. Till now, it’s remained a relatively obscure technology for the enterprise developer. Now, in part thanks to Eclipse, OSGi is emerging as a viable and valuable technology in the enterprise.

Read more

Design Rot

We’ve all experienced that sinking feeling when maintaining a piece of crappy software. Has my change broken the system in some unintended way? What is the ramification of my change on other parts of the system? If you’re lucky, and the system has a robust suite of unit tests, they can offer some support in proving your work. In practice, however, few systems have thorough automated test coverage. Mostly we’re alone, left to verify our changes as best as possible. We might privately criticize the original developers for creating such garbage. It certainly lends a plausble excuse in explaining why the maintenance effort is so costly or time-consuming. Or it might serve as the basis upon which we recommend a re-write. But mostly, we should wonder how it happened.

Read more

A class defines the variables and methods available to it’s specific instances. A class serves as the blueprint for an object. An object is an instance of a class with state. In Java, a class is a .class file

A component is a unit of deployment. A component contains classes. Components are invoked in-process (locally). Components are not instantiable. Components are stateless. Component interactions are synchronous. In Java, a component is a .jar file.

A service is a software system. Services are distributed, may execute in different processing environments, communicate over a network, and are invoked remotely. A service is not instantiable. Services are stateless. Service interactions are synchronous or asynchronous. A service contains components. In Java, a service is an .ear file with the appropriate deployment descriptor.

Agree or Disagree? I’m interested in your thoughts on this subject…

Next Page →