Archive for September, 2008

Yesterday, the second Adam Bien event in Lehmanns Bookstore took place. Again, the event was a full success. I arrived half-an-hour earlier and got a seat only in the tenth row.
Adam spoke about new features of EJB 3.1 and Glassfish. He showed examples running on a developer build of Glassfish V3, promising that the features will work without exceptions…
Here are some topics, I remember:

• Singleton Beans: usefull a s a central point of the application, e.G. central cache etc…
• Async Methods: allows asynchronous execution of time-consuming methods. Especially, it is possible to abort the execution
• Deploying Beans in WARs: could be helpful for small applications
• Global JNDI-Namespace
• No interface view: simplifies the access to beans, if needed
• EJBCOntainer.getEJBContainer().getContext(): allows external initialization of bean context, which is nice for testing

Later, Adam discussed some Core J2EE patters, that become absolete with EJB 3.1 and others which are still valid.

After the talk, I spoke with Adam about the OSGi as a module architecture inside JEE application, which seems interesting to me.

The pictures are as usual available in my FlickR Gallery.

Marco published a video on Loroma.

Posted in enterprise systems, java | No Comments »

The holiday season is over and we can enjoy an event every week. After Maven 2, Eclipse Stammtisch and reasoning on modularity an event on enterprise systems can be visited. It seems that after the last visit on Java EE 5 Hacking Adam want to tell something on Java EE 6 Hacking…

This session will be interactive / openspace like. He will walk through the new EJB 3.1 APIs and explain some interesting stuff as well. It is the logical conduction of the first JUG HH session in May 2008.

Location: Lehmanns Fachbuchhandlung (Hamburg Hauptbahnhof), Kurze Mühren 6, 20095 Hamburg

Date and Time: 16.09.2008, 20:00
Topic: Productive Java EE 6 – Rethinking Best Practices And Bashing On Patterns, Cluster One

Abstract: Java EE 6 is great, but many questions like:

• Are DAOs dead?
• Do JSF really suck?
• Are anemic JPA-entities a best practice?
• Are XML deployment descriptors legacy?
• Are EJBs lightweight?
• How to test EJBs?
• Is layering an antipattern?
• Do we need factories?
• How to integrate with RESTFul services?
• Is it possible to deploy EJBs into a …WAR?
• Are “plain old web containers” dead?
• Services or Objects – what is the way to go?

still remain open. These and many other questions will be discussed interactively with …code.

Speaker: Adam Bien

About the speaker: Java Champion Adam Bien is a self-employed consultant, lecturer, software architect, developer, and author in the enterprise Java sector in Germany who implements Java technology on a large scale. He is also the author of several books and articles on Java and J2EE technology, as well as distributed Java programming. His books include J2EE Patterns, J2EE HotSpots, Java EE 5 Architectures, Enterprise Architectures, Enterprise Java Frameworks, SOA Expert Knowledge, and Struts, all published in German.

As BEA technical director, Bien is also a member of the NetBeans Dream Team; an Expert Group member of the Java Community Process for EJB 3.1, JPA 2.0, and Java EE 6; and involved in embedded Java, Grid, and P2P technology. He currently works as an architect and developer in several J2EE-Java EE Model-Driven Architecture (MDA) and EAI component architecture projects for the Java EE platform and .NET.

Posted in announce, enterprise systems, java, mdsd, tools | 3 Comments »

Yesterday, the OSGi session took place in Hotel East in Hamburg. Peter Kriens, the OSGi evangelist showed a wonderful Zen Presentation on OSGi. I wrote a lot during his talk which happens to me very seldom. Here are the core statements I understood:

• The core difference between usual plugin architectures and OSGi is that OSGi concentrates on collaboration of the components.
• OSGi delivers a controlled environment, in which the question if a component runs or not can be answered in beforehand.
• OSGi bundles use metadata (about versions, dependencies, etc) to predict an error, not discover it in runtime.
• OSGi has a very narrow API containing the minimal common part.
• OSGi consists of module, life cycle and services layers. The initially developed services layer required smart class loading mechanisms (module layer).

1. The module layer is desigend to control the class loading machanisms (e.G. structureal class loader hierarchies instead of a linear classpath)
2. Life cycle layer adds a management API (e.G. inform the others about installation event)
3. Separation of concerns is promoted by definition of services for different tasks.

• Services are used for decoupling of system parts (This is a standard application of service-orientation).
• OSGI makes dependencies explicit (private, import, export)
• OSGI tries to make the system managable, taking dynamics and lifecycle as fisrst-class citizens
• OSGI will be extended to support distribution: the team works on policies, SLAs, etc…

I liked the talk and the way how Peter Kriens addressed the problems of OO. I was confirmed in some ideas about coupling that will be layed out in my thesis. After the presentation we had a delicious meal and wraped up the evening with interesting discussion about pros and contras of OSGi. Peter Friese showed me some remote OSGi staff, he was playing with. The lack of documentation in this area makes it a little difficult, but I hope he will post some news on it. As usual, you can find other pictures in my FlickR gallery.

Posted in java, technology | 3 Comments »

The organizers of the upcoming OSGI event selected a promiment Hamburg’s nightlife location. The location is a evidence of modern design. The entire hotel is equipped with non-standard items in various forms and colors and commemorates on Dali and Gaudi in the same time.

Topic: Why Modularity is Important

When: September 9th, 2008, 19:00 CET, Registration required

Where: East Hotel Hamburg, Simon-von-Utrecht-Strasse 31, 20359 Hamburg / Germany

Abstract: Many developers are finding out that modularity has a significant influence on the development process. But unfortunately, Java has no concept of modularity, all JARs are placed on a linear classpath. Many projects have developed in-house plugin frameworks to achieve some modularity. The OSGi Service Platform is a standards based framework used by many projects. Some of the best known projects that use OSGi are Spring and Eclipse. There are many open source projects and commercial companies that have implemented the specifications: Apache Felix, Knopflerfish, Eclipse Foundation, ProSyst, IBM, Siemens, Hitachi, Samsung, etc. This presentation will analyze the problems with (the lack of) Java modularity and explain how OSGi provides many benefits for the development process as well as make the applications itself easier to maintain and extend.

Author: Peter Kriens

Posted in announce, eclipse | 2 Comments »

On Wednesday, August 27th I visited a presentation about Apache Maven 2. I will describe in short here what I have learned from that event and what you might want to know for your decision if you read more about Maven 2 or not. I will not repeat the basics or advanced features of Maven 2 here, it has been done a million times elsewhere.

Maven 2 is often compared with Apache Ant. Sometimes it is seen as an extension to Ant. This is wrong. So, what’s the difference? Ant is a build tool, meaning you can build your projects with it. Maven is a “project management and comprehension tool”. Project management is actually focussing the technical part, is does not include Gantt diagrams or things like that. What is does include is a description of the technical part of your project, including a source repository, dependencies, documentation, developers and so on. What is the advantage of this?

• Project setup is easier now. No searching for required libs, setting build paths, dealing with other weird stuff
• Project comprehension is easier. The information about the project, the Project Object Model (POM) is human readable. That’s for a reason. Especially in larger projects this seems to be useful to me.
• Changes in projects are tracked easier. Someone includes a new library? All the colleagues’ builds are broken. You have to communicate somehow to your team mates that they have to use that lib. With maven, just check in the new pom file, which includes the new dependency. All your colleagues will get it automatically from the repository you have in your company (hopefully).
• Release management and integration in CI systems comes out-of-the-box. You have all you need to do that. Simply.

Granted, you can do a lot of those with Ant if you are good at it. But with Maven 2 it is a lot easier. As Maven 2 brings a standard project layout, projects not only look similar in their structure every time but they can build in support for a lot of things this way. The pom files are very short compared to Ant build scripts doing the same and more readable. Granted again, you can make your own Ant script containing standard targets you use in every project. You split your Ant files in project specific and general parts. Your project specific part is very short then. Then you did just what the creators of Maven did. Congratulations, you are a smart guy.

I am not saying that all your problems are solved by using it. Maven 2 has some weaknesses as far as I can tell from my limited experience with it. I heard from a participant that the automatic dependency resolving does not work all the time. Normally, Maven would resolve all transitive dependencies from all libs. If lib A is dependent on lib B and you include A in your project, the description of A includes the dependency. Maven will include B, too. I don’t know if that is a failure of maven or the guy who told me about it. AFAIK it needs time to get into it, I often encountered behaviour I didn’t expect. But that was because of my lack of understanding of Maven 2, not because of Maven 2 itself. So, the disadvantage is the same as with every new tool. You need time to learn doing stuff with it, and unfortunately you need to fail sometimes to learn from your mistakes.

BTW, Maven 2 is open source. Everyone who misses something or wants something to get better is welcomed to get into the dev team of Maven 2. One of  those points would be the beloved documentation which has great potential for improvement.

Hope this helps integrating Maven 2 into your understanding of the software development world.

Posted in technology, tools | 3 Comments »