OSGI In Action Book

Java language provides the modularity when designing and coding applications using the Object Oriented Design and Programming concepts. But it doesn't provide a mechanism to take the Java code designed and developed using modular concepts (OOP) to deploy in a modular fashion. This is where OSGi technology comes into picture. You can organize the Java classes using the packaging structure and the scope of the classes to control the visibility of a class to other classes, but when it comes to deploying the applications, you have to package them in a monolithic WAR file or an EAR file which don't provide too much flexibility in controlling what classes and libraries (JAR files) that you want to bundle in the application archive files. This limitation has led to the JEE container vendors come up with proprietary implementations of addressing the modularity aspect (e.g. You can deploy an EAR file as a common library, instead of an application, in WebLogic server).

This is the main focus of the book OSGi in Action by authors Richard S. Hall, Karl Pauls, Stuart McCulloch, and David Savage. It's a good addition to OSGi resources and for the Java developers who are currently using or considering using OSGi technology in their applications.

The book starts with the discussion on what is modularity, Java's modularity limitations related to classpath and limited modular deployment support in Java model and explains how OSGi technology addresses these limitations.

The authors talk about the two parts of OSGi Platform:

• OSGi framework (this is the run-time environment that provides OSGi functionality) and
• OSGi standard services framework (which defines the reusable APIs for tasks such as Logging and Preferences).

They also discuss the three layers of OSGi specification:

• Module Layer: This layer covers the packaging and sharing the code. It defines the OSGi module concept, called a Bundle, which is a JAR file with extra meta-data.
• Lifecycle Layer: This layer provides the run-time module management and access to the underlying OSGi framework. It defines the bundle lifecycle operations like install, update, start, stop, and uninstall.
• Service Layer: This layer covers the interaction and communication among modules, specifically the components contained in them.

The authors discuss the Bundles concept in OSGi, how to define them with metadata and the benefits of modularizing the program. These benefits include:

• Logical boundary enforcement
• Reuse improvement
• Configuration verification
• Version verification
• Configuration flexibility

The event model support in OSGi is also covered.

OSGi Event Model
The OSGi framework supports two types of events:

• BundleEvents (these events report any changes in the lifecycle of bundles) and
• FrameworkEvents (these events report the changes in the framework).

The authors also talk about the OSGi design patterns such as Listener and Whiteboard and some OSGi anti-patterns in the areas of updating a bundle. Best practices in managing the versioning of packages and bundles, how to run multiple versions in the same JVM with the example of a Preferences service.

The discussion in the book includes a sample Java application (paint program). The application build and package examples use Ant as the build tool. It would have been nice if they used Maven tool which is what I use at work for building and packaging the Java applications.

There is also discussion on how to test the OSGi applications using mock objects approach when calling the OSGi APIs and container testing to discover any potential class loading or visibility issues. The OSGi test tools listed are OPS4J's Pax-Exam, Spring DM's test support, and Dynamic Java's DA-Testing.

Topics like debugging Java applications and embedding the OSGi framework in applications are also covered. Security, another important aspect in enterprise application deployment, is also covered in detail.

To put OSGi in perspective, the authors also talk about how OSGI relates to other technologies like Java Enterprise Edition, Jini, NetBeans Platform, Java Management Extensions, Lightweight containers (PicoContainer, Spring, and Apache Avalon), Java Business Integration (JBI), JSR's 277 (module system for Java) and 294 (Improved Modularity Support in the Java Programming Language), Service Component Architecture (SCA) and .NET technology.

Overall, this book is an excellent resource for Java developers of all levels of expertise in OSGi technology.

ITARC Austin 2010 Conference

I will be speaking at the upcoming IT Architect Conference (ITARC) in Austin this week. My presentation sessions details are as follows:

Fundamentals Track:

• Integrating Enterprise Architecture into Agile and Lean Software Development Environments
• Security Architecture Policy Enforcement and EA Governance Using AspectJ and SpringAOP Techniques

It's a conference worth attending with a great line-up of speakers and sessions and the registration price is very affordable.

There are two keynote presentations.

• Keynote: Gaining Operational Excellence and Agility Through Enterprise Architecture, Presented by Roy Hunter, Senior Director, Enterprise Architecture at Oracle
• Afternoon Keynote: IT Complexity Crisis; Danger and Opportunity, Roger Sessions CTO, Object Watch

Check out the conference agenda for more details on other sessions. I am looking forward to the conference.

Austin Marathon 2010

I will be participating in the half-marathon event at the upcoming Austin Marathon.

I have also signed-up for volunteering at the Expo Packet Pick-Up on the day before the race. I did the same for the Decker Challenge Marathon relay last month and it was lot of fun.

I am participating in the marathon as part of a group called Run For India (RFI) Austin Chapter which is part of A.I.D (Association for India Development), a charity organization. If you like to donate to this group, please use this link.

I am looking forward to the marathon.

Java EE 6 Features: Dependency Injection, Bean Validation and EJB Enhancements

Java EE 6 was released on Thursday this week. I wrote about it on InfoQ website. The latest release is major in terms of breadth and depth of the new features included in the release.

Some of the main features in JEE6 include:

• Dependency Injection
• Bean Validation
• EJB Enhancements
• Servlet, JSF, and JSP Enhancements
• JAX-RS API

Check out more details on the new release here.

Menlo Tour - How Agile Software Development is Done at Menlo

Last month, I visited a software consulting company called Menlo Innovations located in Ann Arbor, Michigan. Menlo has been using Agile methodologies in their Software Development processes for last eight years. Menlo hosts the tours every month at their company office to show the visitors how they do agile software development.

James Goebel was our host at the meeting. It was a very good experience to see a team of teams doing the agile software development and how they have perfected an unique development process that works for them to be successful in their software development projects.

They use several eXtreme Programming (XP) development and testing techniques.

Here are some high-level details of their agile process:

• Iteration Length = 1 week
• High-Tech Anthropologists (HTA's) write the user stories working with the client and the project team. They write the stories through the eyes of the customers. User designs are also done by HTA's.
• They use big white papers, charts, and tasks with color coded statuses to make the project progress visible to every one in the team w/o having to dig into several different project management software tools.
• Their projects range from 1-day to 4-years in length and all different business domains in nature.
• The Daily stand-up meeting is at 10 am every morning and every one in the building (all project teams, HTA's, QA team, clients, vendors if they happen to be in the office at that time) attend the meeting.
• They review the story cards every day to monitor the progress and identify any roadblocks to complete their tasks. They follow the strict rule of, if there is no card on the board for a specific task, the project team must not work on that task. So, "No Card, No Work, No Money".
• Their revenue model is based on the royalty and partnership based (on some projects) so they take the quality, customer satisfaction, and long-term health of their software products very seriously.
• If a pair has to stop a particular task because of some dependencies or roadblocks, they put a red dot on that task indicating that the work has been stopped on that task, and start the work on a new task (with yellow dot on it showing that it's in progress).
  

Fail Fast:
They believe in the concept of make small mistakes faster and often. James gave us an example of how they managed a previous project in an iterative manner to successfully deliver what the customer needed out of the project. It was a small project with 1-day deadline. The first time they worked on the project, they worked on for the whole day and didn't finish it on time. Then they worked on the same project again in 1-day with great success, the only difference is this time they followed a eight 1-hour iterations rather than one 8-hr iteration. And on the second day, after 2 hours into the project, they found where they got stuck the previous time, and made the necessary adjustment (following the "Inspect and Adapt" philosophy we hear in the context of the Agile project management)

Color coded status tracking:
They use a color coding system to track the status of project tasks.

• Red = Task Stopped
• Yellow = In Progress
• Green = Completed

Projects don't move, people do:
They have dedicated areas (basically a corner of one big office room) for each project where the project tasks, information reports and charts are displayed on the wall. Since the project status reports and other artifacts in a specific area, it's the team members who move to the project area when they need to work on a project, rather than the other way around.

Pair Programming:
Change the partners every week so the pairs don't get used to each other's poor development practices (for example, not writing unit tests).

Test Driven Development:
They religiously follow Test Driven Design/Development (TDD) philosophy.

Build is Broken - Uncommit Your Code:
If someone's code caused a unit test or the whole application build to fail after code check-in, the team has to either fix the build errors in a reasonable time or "Uncommit" the new code so the build will succeed and the other developers can move forward with testing their features on the Integration server.

Time Estimates:
Every one in the project team estimate all the tasks and the project lead uses the most common estimates (by taking away the lowest and highest time estimates). The time estimates range from 2 hours to 1 week (i.e. 2, 4, 8, 16, and 32 hours). If a task is estimated to be higher than 32 hours (e.g. 64 hours), those features have to be split into smaller tasks so they can fit in a single iteration.

They also use different sizes of the paper for tasks with different estimates, so they know how many tasks can fit in an iteration. For example, they use 8.5 x 11 paper size as the 32 hours. And the team can only have use one 8.5 x 11 sheet to fit the tasks for one iteration, meaning they can put one 32-hour tasks, or two 16-hour tasks, or one 16-hour and two 8-hour tasks, you get the point. This approach sounds very interesting and it works great if you think about it.

Every thing (estimations, development, unit testing, show & tell, and the delivery of CD) happens every week.

Show and Tell: For Customer, By Customer:
At the end of each iteration the project team creates two CD's of the working software and gives one CD to the QA team and another to the client. The QA team's job is to verify the health of the overall software package, not just test each feature in isolation.

And when it's the time to demonstrate the software created in an iteration, the team works with the client to install the software on the client's PC and let the customer show (demonstrate) the software product to the team.

They don't really use any software tools for the project management purposes. Other than Microsoft Excel to keep track of the time spent on tasks and the project, every thing else is done on a piece of paper. It was amazing to see how they are able to be agile without really using a tool for writing user stories and other tasks. This is the proof that the agile development teams should focus on the results and not the tools.

Other Observations:
Their software development process is created around the social constructs of the team. For the new prospective team members, they look for the ability to learn and team player skills.

James said that we should ask the following question to ensure that what we are working is going to add value to our company goals:

"How does your job impact the bottom line of your company?"

Conclusions:
They have been following the mantra: "Continue doing what works & Stop doing what doesn't work".

If I have to pick two things that Menlo teams seem to be following, they would be: "Team Collaboration" and "Collective Discipline".

James was an excellent host of the tour and he is also a great speaker. I learned a lot about how Agile Development Process works @ Menlo and apply some of the ideas in my projects.

Like said, it was a very good learning experience for me to be part of the tour and I encourage every one who lives in the southeast Michigan area to sign-up for the next tour which is actually the coming Wednesday.

Role of Code Generation in Java Application Development

I recently wrote an article on InfoQ about the role of code generation in Java application development. There have been different tool vendors (Spring Roo, Skyway Builder Community Edition, and Blu Age's M2Spring) announcing Code Generation tools in the recent months, so I thought I would write a tool round-up type of article summarizing these tools.

Check out this Q&A article on InfoQ:

http://www.infoq.com/news/2009/09/codegen-java-development

JEE Web Development Framework Requirements Revisited

There is an excellent blog post on choosing a web development framework/toolkit by Ilya Sterin. It captures very well most of the web app framework requirements and limitations we all face on a daily basis in our projects.

As mentioned in the write-up, most of the J2EE developers think, at one time or the other, about what features they really need from a web application framework and why there is no single framework that supports all those features.

If I have to pick top 5 features I look for in an ideal web application framework, they would be:

1. Isolation from the domain layer so presentation and domain layers can evolve independently w/o (adversely) impacting each other.
2. Simple and Easy Data binding between the Domain, Controller, and Presentation layers, so the developers don't have to write unnecessary and useless boiler plate code to convert the same data from a DO -> DTO -> Struts Action Form -> JSP/HMTL field to just select some data from a back-end data store anddisplay it on a web page.
3. Support for data validation that works in all the layers w/o any additional coding.
4. Support for AJAX functionality.
5. Controller class methods can be exposed as RESTful Web Services w/o lot of extra coding or configuration.

The presentation layer classes should also be unit testable w/o having to deploy the web application into a container.

Ilya talks about the persistence concern as well. Unless the web application in question is a simple data driven application that can use a solution like RoR or Grails, I am not sure if persistence is really a concern from the web application side. In an ideal architecture, presentation layer should never access the persistence layer directly. It should always go thru the domain layer for the retrieval and modification of the data stored in the back-end data store. So, if the domain model and its boundaries are well defined and implemented, I don't worry too much about the persistence concern when I look for a web application framework.

I have been using Spring MVC in the recent projects. It supports all the items listed above except for the AJAX support. But I read that Spring WebFlow framework (which includes Spring JavaScript and integration with Dojo) has AJAX support, so that's good news for the developers who are using Spring.

I am also eagerly waiting to start using Spring 3 framework which makes it even easier to expose controller class methods as REST web services and also has Expression Language (EL) support which is another nice feature to have when working in the MVC part of an enterprise application.