Essential OSGi Animated Video Series

In my book, Essential OSGi, I'm using Blender to build pictures of difficult concepts. For example, I'm using physics simulation built into Blender to get a picture. Behind the scenes, I see the 3D animation as a movie. My book only includes one frame as a picture. I'd like to illustrate how things change over time, which is something difficult for me to do in a written presentation. It's kind of a technical 3D animation with Blender.
JAR
To illustrate the concept of a JAR in Java, there's nothing better than a glass or plastic jar from the non-technical world. Just as you add classes to a JAR in Java, you can add something to a jar in Blender. With animation, I can illustrate how a JAR changes over time.
Other concepts
How do I illustrate a class? a package? a module? a class library? How do I illustrate using revolution as a software development strategy? using evolution as a software development strategy?
Plus, modules have been used outside of the Java world. Software has been maintained outside of the Java world.
Conclusion
I continue to work toward posting the original 3D animation used to produce the picture in my book.

Monolithic vs. Modular: Definintion

I advocate moving an application from monolithic to modular. When working with the current programming language and tools, I advocate modular-by-convention because true modularity isn't possible.

It reminds me of the argument to move from structural programming to object-oriented programming. What? Isn't object-oriented good enough for programming-in-the-large?

At the end of the day, I don't get it. Who wouldn't want to reap the benefits of modular object-oriented programming in Java? Who wouldn't want to maintain an internal API -- between component parts of an application, not just an external API for external component parts?

The answer is simple. We use the term "modular" without clear definition. What does it mean exactly?

It means independence. You can write, develop, test and deploy a module without regard for everything that everyone else is doing. A feature of an application is independently deployed to the production environment. It is compiled independently from everything else that needs to be compiled. It is built independently.

A module is loaded at runtime -- independently from all of the other modules. It is unloaded independently.

This independence means that a feature can be developed in isolation, tested in isolation and used in a production environment without nasty surprises because of unknown or unexpected interaction with other concurrent modules.

If you are installing and upgrading software from a DVD ISO9660 image, it isn't exactly modular, is it?

If you are upgrading production components after hours, you're not modular.

If your build engine recompiles all of the components in your application in order to create the new build, you're not modular. (You do have a build engine, don't you?)

On the other hand, if multiple versions of business logic are running simultaneously in your production environment, you might be modular. Maybe.

Is your Java application modular in the same way that your GNU/Linux operating system is modular? To upgrade your kernel, do you have to reboot your computer? To upgrade your production application, do you have to restart your JVM?

cjos Command in OSGi

From the osgi> prompt, the cjos command is the entry point to CjOS (the C++/Java Operating System). What can you do with the cjos command?

Any CjOS command
At a CjOS prompt, you can run any CjOS command without the cjos prefix. To embed CjOS in OSGi, without clashing with any existing OSGi command, we've implemented the cjos command as a prefix. The console for a CjOS command is redirected to the OSGi console.

ub command
osgi> cjos ub

The ub command is an entry point for the command-line Universal Browser. This browser uses the Smart API to resolve a URI. To run the browser in OSGi, use the cjos prefix.

For more information on available schemes, see also the JOS Technical Edition.

Example
osgi> cjos ub controller:resource:

This specification displays additional information about the resource: controller. A controller is a Java class; it implements one or more schemes.

smartlist command
osgi> cjos smartlist

The smartlist command displays a list of active schemes in Smart API. To run this command in OSGi, use the cjos prefix.

CjOS Project Revisited

The CjOS Project is a research project for a Java-based operating system with a combination of C/C++ and Java. The project has an emphasis on the Java-side of a Java-based operating system. The project has an emphasis on desktop, laptop and server machines. The project has emphasis on long-term stability of both API and implementation we like to call perfect backward compatibility.

Recent activity
One of the most active parts of the project right now is the investigation of OSGi. We're building OSGi modules from a large, monolithic Java class library.

Release 1.0
In addition, the first release of the OSGi initiative is now available. It brings many of the production-quality APIs from the CjOS Project to OSGi-compatible applications, such as the Eclipse platform and IBM WebSphere Application Server.

Example
Allow me to provide just one example of what you can do now. The Smart Archive feature enables your Java application to read a file inside an archive inside an archive inside an archive--without the use of temporary files. It also enables you to find files inside an archive inside an archive inside an archive--without the use of temporary files.

Tradition
The CjOS Project maintains a collection of Java archives. Traditionally, these Java archives are delivered to the Linux platform as a corresponding collection of RPMs. By adding the CjOS Project archives, you enable your Java application to benefit from a large, stable, backward-compatible, monolithic class library of working Java code.

Modular initiative
The previous collection of Java archives do not map directly to a collection of OSGi modules. Using the power of the XVCL Processor, we're re-generating existing Java source code into OSGi modules.

Discovery
By moving to OSGi, we have discovered and fixed hidden problems in our design and implementation. So, the OSGi initiative has improved the overall quality of the project.

Check it out
Download the recent release and experiment with it inside of your OSGi application.

Thanks for listening,

Monolithic vs Modular Java

To start this series of articles on OSGi, we'll take a look at the difference between monolithic and modular.

Why is it important?
Monolithic and modular Java are part of the same software architectural spectrum. How much is monolithic and how much is modular in your Java application should be an explicit choice. How do you decide?

Non-Motivation
We hear people talking about modular Java. We see books on modular Java. Does that mean that everyone should start developing with a modular architecture? No, you decide if modular is right for you.

Monolithic Java
A monolithic class library is where all classes are part of a single, monolithic namespace. While there may be separate collections of Java archives, the namespace is reduced to a single list.

Simplicity. The monolithic class library is the original model. It is a simple model. All classes are available all of the time.

Very large namespace. The monolithic class library is a viable alternative for large business applications because Java supports a very large namespace. Hundreds of thousands of classes can be used in a business application without loading two classes with the same name at the same time.

In other words, many programming languages prior to Java technologies have been limited by a small namespace. The name of a dynamic link library on a well-known operating system, for example, was limited to just eight characters. Java technology has a limitation, too; but, it is sufficient to say that it is more than a hundred characters.

Static class path. When a class path that is static, it never changes throughout the lifetime of your Java application. This means that the potential list of available classes never changes. Classes are neither added nor removed during the lifetime of an OS process.

Modular Java
A modular class library is where there are multiple, concurrent namespaces. The namespace becomes a tree rather than a list.

Version. Technically, the Java technologies are quite capable of loading two classes with the same name as long as they are loaded by two different class loaders. This has been true since the first version of Java (JDK 1.0).

Volatile class path. When a class path is volatile, it is capable of changing over the lifetime of an application. Classes are added and removed without starting a new OS process.

Complex. Dynamic loading of a Java class involves a little more complexity. A fully implemented module system involves a lot of complexity and resolving a lot of issues.

Moving from monolithic to modular
Changing a software architecture requires research, investigation and establishing a new set of constraints and rules. When classes have been developed in a monolithic software architecture, they must be redeveloped in a modular software architecture. Fortunately for Java classes, redevelopment uses a lot of the same tools with different techniques.

Is it worth the effort?
The big question is: Is modular worth the effort? The answer is maybe yes, maybe no. It doesn't make sense to move everything written in Java to a modular software architecture. A lot of Java code has been written in a monolithic architecture and is fundamentally incompatible with a modular architecture. In other words, some class libraries should not be modularized.

Each class library needs to be evaluated for the benefits of modular architecture. And, ultimately, the benefit of maintaining a loosely-coupled collection of modules should be evaluated. What do you hope to gain from it?

About OSGi
One of the benefits of developing OSGi modules is running applications in Eclipse Rich Client Platform and one of the many Java application servers, such as IBM WebSphere.

One Reason to Use EGL: External Types

Whew! I just finished working on a major software feature for my ultra-conservative corporate customer. It provides me with one great reason to use EGL, and specifically, the EGL Development Toolkit (EDT).

I was asked to do the (seemingly) impossible: Duplicate an existing process to create form letters. A few thousand different forms needed to be converted to the new process. While BIRT might have been a general solution to the problem of producing PDFs, there wasn't enough time. I've used BIRT successfully. Generally, I would recommend it. But, designing a few thousand BIRT reports didn't seem to be the right answer.

I used EGL to prototype the PDF generation process. While the development environment was strictly Rational Business Developer, I chose EDT as the tool to build the prototype. And, I'm really glad I did. EDT provides a New | External Type feature, to generate external types from an existing Java library. I imported the iTextPdf library (at www.itextpdf.com). I bought the electronic book: iText in Action.

Within a few minutes, I generated my first PDF. It wasn't much. Writing the code in EGL made it easy to think about the problem in high-level, business-logic terms. I was able to change my mind several times while exploring different designs without the complexity of refactoring Java source code. And yet, external types enable me to use the off-the-shelf iTextPdf library, with all of its power to read and write PDFs.

I connected my PDF generator to a frame library (Framing Software, XVCL) to store key-value pairs in an SQL database. In this specific case, an analysis of a few thousand forms showed a very distinctive pattern and consistency of purpose for the form letters. Knowing exactly what needed to be produced, I was able to create a custom form letter editor. The letter editor provides a mechanism for variable substitution (lifted directly from Apache Ant).

And then, it hit me. The original form letters were composed with Microsoft Word and stored in an open document format. Tapping again into the power of EGL and external types, I imported the text (but not formatting) of the existing form letters into the frame table, using an EGL business logic library. With the text of the form letter in the editor, it was (relatively) quick and easy to add formatting to recreate the original form.

Importing from Microsoft Word to a BIRT report is beyond my technical skill at the moment. This turned out to be the right answer to the specific problem facing the customer. They needed a new way of generating form letters in their production system and, with demands from their customers, they only had thirty days to do it.

Working with EGL alone, I wouldn't be able to finish the project. And working with Java alone, I wouldn't be able to quickly build a succession of prototypes, trying and working through different design ideas.

The best design was selected and imported into Rational Business Developer. While the syntax is similar, EGL written with EDT did not simply drop into the customer's version of RBD. It had to be reworked, especially lack of support for a question mark (?) at the end to indicate a nullable type. At the end of thirty days, end-users were generating customizable PDFs using production web application.

Now, that's a good reason to use EGL. What do you think?

Essential EGL+Batch - Lesson 27 SQL Prepared Insert

Use a prepared select statement to search for records.