Adam Bien's Weblog   

The JavaWorld's article "iBATIS, Hibernate, and JPA: Which is right for you?", explains really well the concepts behind iBatis and Hibernate. I'm not fully agreed with the explanation of JPA. JPA is nothing else then an abstraction layer, which encapsulates Hibernate, TopLink, openJPA or JPOX. You only have to rely on the API and not the SPI (Service Provider Interface). JPA is enough for most use cases, everything else can be usually solved with the proprietary extensions of the particular SPI/provider/"driver". From the "simplicity" point of view I would say the following:

• JPA is the simplest solution. The amount of XML is minimal. It is dry. For the simplest example you have only to know two annotations: @Entity, @Id. See: EJB 3 Persistence (JPA) For Absolute Beginners - Or Create Read Update Delete (CRUD) in 2 Minutes And Two (library) Jars
• Hibernate: I would differentiate, whether you are going to use Hibernate with the "classic" XML configuration, or the annotation driven approach. The first case is harder to maintain, the latter very similar to JPA.
• iBatis is the most powerful, but not that simple. It comes with highest amount of XML-configuration, which has to be maintained during the whole lifecycle. The tool support is rather weak. It differs sematically from Hibernate and JPA already on the conceptual level; it is more comparable to DAOs, than ORM. Fetched objects are immediately detached, and have to be merged after every modification. This is very different to JPA and Hibernate.

Comparing JPA with Hibernate, is like comparing JDBC with e.g. native Java DB / Derby drivers. The first is standardized, the second one more powerful. In my opinion: you should always start with the standard. Standard means: more than one vendor / provider.

The article is still interestingand readworthy, I have only problems with the conclusion :-)

Posted at 12:22PM Jul 31, 2008 by Adam Bien in Enterprise Architekturen, Leitfaden für Effiziente Softwareentwicklung  |  Kommentare[0]

 Subscribe in a reader

Plugins, modules, bundles and decoupling seems to be sexy nowadays. I remember the disappointment of an architect in one of my past projects, as we went into production with only five plugins. He expected more, but the customer was absolutely happy with the result, as well as the provided flexibility. I asked him, why we need more plugins - his answer was: "because of modularization". But: It is hard to find a customer, which just pays for modularization :-).

Modularization helps to structure the application, but as every other architectural paradigm, it has it's challenges as well:

1. Every plugin / module / bundle comes with metadata which defines provided and required dependencies. This data has to be provided somehow, it isn't DRY (don't repeat yourself) in general. At least the names of classes, interfaces etc. will be listed in the configuration. You will need specific tools (Eclipse, Netbeans) to maintain that metadata, otherwise refactoring could become a nightmare.
2. At least "provided" dependencies are often realized as Java interfaces. The plugins are decoupled from each other via interfaces. Not every technology is compatible with this approach E.g. relationships between JPA objects can be hardly expressed with interfaces. The result: the whole domain model is packaged in one plugin...
3. The governance can become hard. The dependencies between plugins (and their versions), has to be configured somehow. But: how many version do you would like to maintain in parallel? This problem is similar to the SOA-challenges. See: "How To Kill A SOA Project" as well.
4. Funny story: after the deployment many customers do not want to be able to load and replace parts of the application at runtime. This could become too hard for the end users (sometimes even for developers) to maintain. In most of my projects, we had to disable the update site / plugin management capabilities in "production".
5. In most companies the release cycle for desktops apps is predefined. The applications are just shipped as a "blob". From the deployment point of view it is easier to deploy one single file, instead of many interconnected chunks of functionality.
6. Most of the frameworks like JPA (Hibernate, TopLink), Log4J etc. have problems with specific classloading in Eclipse / Netbeans RCP (there are issues in both cases). In Eclipse land the projects often go to production with "Eclipse-BuddyPolicy". Then the plugins are able to export / import the classes directly - actually a hack...
7. Sometimes bidirectional relations between plugins are required, because of business requirements. Most of the plugin "containers" have their problems with bidirectional dependencies. Bidirectional dependendencies are not "beautiful" but sometimes required in real world. You can of course obfuscate them with reflection or other hacks, or deploy the dependent parts in one bigger plugin. The problem here: the plugins are not designed in respect to business, but deployment point of view.
8. Performance is not an issue in general. Nonetheless plugins can influence heavily the startup performance. Just try to start Eclipse SDK, then one of the commercial offering built on top of Eclipse (Rational, SAP, BEA etc). You will see the difference :-). 
9. It is hard to find good extension points in advance. They are often too generic or too specific.
10. In contrary to technical stuff and IDEs, business software is not always that extensible. The customers do not think in replacable algorithms. It is often hard to say which parts are instable (or are changed often), and which are rock solid. This is rather simple for IDEs, but much harder for business applications. Often the algorithms in real world are not going to be replaced very often.
11. Usability can suffer. Best example: Glassfish. Glassfish v2 can be installed with few clicks. Glassfish v3 either. BUT: you have to have an internet connection to download e.g. the admin console after the installation. The modules can be dynamically downloaded and installed, but it can go wrong and is not as convenient as in the rather monolithic Glassfish v2. Although Glassfish v3 is modular, it will be surely (hopefully :-)) distributed in predefined profiles, rather then with a micro kernel and tons of dynamic modules.

Nonetheless, modularization is much better then monolithic applications. Building cohesive and independent units is always a good thing. But they do not have always to be dynamic reloadable, installable and replacable.The modules should be designed according to the functional requirements, and not driven by the capabilities of the "plugin-containers". Just: Keep It Simple...

Posted at 04:53PM Jul 30, 2008 by Adam Bien in Java EE 5 Architectures And Idioms  |  Kommentare[0]

 Subscribe in a reader

Since my last post, I forgot to switch from 6.5m1 to 6.1 and used the 6.5m1 accidentally for all my projects (about 13 project groups, about 100 different projects). It worked surprisingly well for almost three weeks, ...without restarting (I just hibernate my notebook, instead of rebooting it). Just after the comment regarding anti-aliasing I recognized, that I actually working with milestone. Some observations:

1. Anti-aliasing seems not work; in my case it just looks different - I thought it is a feature and not a bug :-).
   
2. I installed new Glassfish instances, restarted Glassfish, redeployed different Java EE 5/6 applications (EJB 3, JPA, Rest, SOAP) several (hundred) times - it was rock solid, no issues so far.
3. Free-form web projects work just well. I imported an already existing web projects and used external ant to build it. It worked just well.
4. As I switched back to 6.1 for a training - I noticed that 6.1 seems to be a little be slower, than 6.5.
5. The Ctrl+I search is really useful. It actually searches for commands and is able to execute them. However it searches in the open files either, and combines it with "Go To Type". Pretty useful. You can just open a "missed" file, or deploy an application without knowing where the command / menu / toolbar actually is...
6. I switched back to 6.5m1. It works fine so far.

Posted at 07:12AM Jul 28, 2008 by Adam Bien in Netbeans  |  Kommentare[0]

 Subscribe in a reader

The workshop description is now online (see my recent post as well). If you prefer English, come to San Jose - to the first U.S. JAX conference. In Germany / Europe this conference is almost legendary, hopefully it will be successful in U.S. as well. Feel free to contact me at this events for critics, ideas and discussion.

Posted at 01:17PM Jul 26, 2008 by Adam Bien in Events  |  Kommentare[0]

 Subscribe in a reader

The first start/installation of JFtp (see screenshot) via WebStart takes about 10-20 seconds. All subsequent starts about 5 seconds - (on Java 6u10). Another great sample for WebStart, Swing and Java 6u10 combo.
Btw. it is a Ftp, Http, Ssh, SMB etc. client :-).

Posted at 09:25AM Jul 25, 2008 by Adam Bien in General  |  Kommentare[1]

 Subscribe in a reader

I was asked whether I know some capable Java EE 5 developers. I know some, but the community is bigger, than my social network, so; if you are interested in a job, drop me an email or leave a comment. I do NOT expect fees etc, except perhaps a free beer at JAX, W-JAX or at one of the Java ONE parties (is free anyway) :-).  I will just forward the emails. I will spend some time in this project as well. I'm asked more and more about Java EE 5 developers - it's interesting.

Posted at 11:47AM Jul 24, 2008 by Adam Bien in General  |  Kommentare[2]

 Subscribe in a reader

If you already invested the three minutes working through the post "EJB 3 (@Session) For Absolute Beginners - 3 Minutes Bootstrap, 5 Steps", you can skip the requirements section.

Requirements:

1. Installled JDK 1.5 (better 1.6) 
2. An IDE of your choice e.g. vi, emacs, netbeans 6.1 (SE or EE), Eclipse Genymede (SE or EE)
   
3. @Stateless, @Local, @Entity, @Id Annotations in classpath
   
4. An Java EE 5 capable application server of your choice. It will work with Glassfish v1+ (better v2), JBoss 4.2+, WLS 10+ and probably Geronimo (not tried yed)

What is Dependency Injection (DI)?

DI is a fancy term for a simple thing: someone (in this case something -> the EJB 3 container) cares about managing the dependencies for you. You just have to declare the need for it.
EJB 3 is using annotations for this purpose, absolutely NO XML is needed.

Basically: everything which is stored in JNDI can be injected, instead of "looked up".

What is to do:

1. To inject one Session Bean to another use the @EJB annotation:
   @Stateless
   public class BookServiceBean implements BookService {
       @EJB
       private SearchService search;
   
   Common error: you cannot inject classes in EJB 3.0, but only interfaces. This will change in EJB 3.1...
   
   
2. To inject a DataSource, Queue, ConnectionFactory, Mail, SessionContext etc. you will need the @Resource annotation:
   @Stateless
   public class BookServiceBean implements BookService {
      
       @Resource(mappedName="jndi/sample")
       private DataSource ds;
   
   
3. To use the persistence, just use the @PersistenceContext annotation:

How it works:

EJB 3 DI operates in "Convention over Configuration" mode. So in general: in case there is only one possibility - it will be injected.
If there are more than one, you will have to configure manifesting your choice...

The easiest possible start:

...is with Netbeans 6.1 (EE) -  download the first choice (139 MB - all included). It will not only install the IDE, but the application server (Reference Implementation: Glassfish RI), sample database etc. Eclipse's Ganymede is good as well, however you will need more projects (one for EJB 3, one for JPA), setup the application server etc. so it takes slightly more time if you are an absolute beginner :-).

Why is it good:

1. No overhead - the code is as lean as it can be (any suggestions to make it simpler? :-)). The jar contains nothing else, but the interfaces and classes.
   
2. It's simple - and sufficient for most use cases.
3. Is easy to test: the reference can be set in JUnit directly (I will cover this in one of the next posts)
4. Is configurable - all annotations can be overruled by XML. Even legacy POJOs can be integrated that way. See an extrem example - the deployment of a Swing Table Model as EJB 3 :-).
5. No vendor lock in: EJB 3 is one and only component model I now, which is vendor neutral, with several available implementations (JBoss, Glassfish, Weblogic, Websphere, openEJB, SAP, Spring Pitchfork, Geronimo + forgotten ones). Google Guice is, however, promising as well. The dependency to EJB 3 spec itself is low - if it does not work for you, you can deploy this "pojos" to something else...
6. The EJB 3 container is able to monitor (see e.g. Glassfish CallFlow) the whole invocation chain of EJBs. If you are developer: you probably don't care, but your operations :-)
   

Posted at 01:18PM Jul 23, 2008 by Adam Bien in Java EE 5 Architectures And Idioms  |  Kommentare[1]

 Subscribe in a reader

During Glassfish v2ur2 EJB 3 tests together with JPA persistence I enountered the following problem: Direct changes to the database (SQL updates) performed using an injected DataSource in the same Bean-method, and so transaction, were not visible for the operations performed on the EntityManager (subsequent find). Only the old (cached)  entity was visible, without the changes performed in the DB.

@Stateless
@Remote(VehicleManager.class)
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public class VehicleManagerBean implements VehicleManager {

    @PersistenceContext
    private EntityManager entityManager;
    @Resource(mappedName="jdbc/db")
    private DataSource dataSource;
 }

Both resources; the EntityManager and DataSource participate in a transaction, so direct changes to the database should be visible to the EntityManager as well.

Nevertheless in the method below, the last find-method didn't reflected the changes made in the DB:

public Vehicle findChangeDBClearFind(int id, String newColor) {
        Vehicle vehicle = this.find(id);
        try {
         //changes the color of the vehicle directly in the DB
            this.changeVehiclesColor(id, newColor);
        } catch (Exception e) {
            throw new EJBException("Problem executing statement" + e, e);
        }
        this.entityManager.clear();

                    return this.find(id);
    }

 private void changeVehiclesColor(int id, String color) throws Exception {
        Connection connection = this.dataSource.getConnection();
        Statement statement = connection.createStatement();
        String sqlStatement = "update vehicle set color=\'" + color + "\' where id=" + id;
        int updatedRecords = statement.executeUpdate(sqlStatement);
        if (updatedRecords != 1) {
            throw new IllegalStateException("Vehicle with id: " + id + " cannot be updated!");
        }
        connection.close();
        statement.close();
    }

I assumed first, that the problem was the DataSource configuration. It turned out, however, that in the default configuration, TopLink essentials will not join the existing transaction. This can be achieved with the following setting in the persistence.xml:

        <property name="toplink.transaction.join-existing" value="true"/>

The property above is only available for TopLink Essentials 2.1 and so only for Glassfish v2.1+,v3 and not for Glassfish v2ur2. However I replaced the installed toplink-essentials.jar and toplink-essentials-agent.jar in the [GLASSFISH_HOME]\lib (existing Glassfish v2ur2 installation), and it worked as well. It is actually an already known bug. Btw. I tested Glassfish v2ur2 during the last weeks intensively, and this was the one and only  major issue. Beyond that I enountered only problems merging entities with @Version fields with the "big" types like Long, Integer etc. which is uncommon in real life project. I filed this bug as well. Thanks to Gordon Yorke for providing the property and the hints.

Posted at 02:52PM Jul 17, 2008 by Adam Bien in Java EE 5 Architectures And Idioms  |  Kommentare[1]

 Subscribe in a reader

It happened what I actually didn't expected any more. The software produced by Sun is not only working, but is really usable, easy to install and highly regarded outside Sun as well. Sun's "Software Division + Open Source Community" really caught up. Just few samples:

1. VisualVM - useful troubleshooting tool.
2. JavaDB - powerful, lean embedded / distributed Java DB 
3. openDS -  easy to install (even with WebStart) ldap server
4. Wonderland - no comments, just cool.
5. Glassfish: from "nothing" to killer appserver. V3 comes with some singnificant usability improvements like easy embedding etc.
   
6. Netbeans: before 5 it was unusable (sorry - hardcore Netbeans lovers :-)). Netbeans 6.0 > was really improved in order of magnitudes. Netbeans 6.5 could become the hub of different langauges (Groovy, Scala, JavaScript, Ruby, Java). Although IDE is a religious topic - there is no doubt in signifcant improvement in the quality, performance, usability, documentation and features (I used it all the time)
7. openesb - really interesting "Enterprise Service Bus" the new version is even OSGI based.
8. virtualBox - really amazing: a 20 MB, free and powerful virtualization tool
9. openSolaris - I only installed it in VirtualBox, during a really boring (almost funny), sponsored JavaONE's General Session. The installation is really easy, the UI nice. I heard only good things about ZFS and Dtrace
10. hudson - easy to install, and configure (without XML), continuus integration tool.
    

Sun's strategy (what I understand from outside), is giving away great software, and sell so more hardware. But is seems like there is not really easy buying hardware from Sun - or only few people know what the offerings actually are. From my perspective Sun is not leveraging the potential here (perhaps with the exception of SunSPOTs). Some samples:

1. I bought and assembled a linux server, and recognized one year later, that the T2000 entry server wasn't much more expensive.
   
2. I wondered on a fair/tradeshow in germany about a nice workstation (aluminium finish), similar to Mac Pros, and recognized it is Sun's product - with AMD or Intel Chips and available Windows, Linux, Solaris options. No one on the booth could tell me how to get one. I bought other hardware half year later...
3. I found the workstation on Sun's homepage. There is only a small image available. There is no possiblity to enlarge it. Just compare this online product presentation with e.g. Apples Store, and their workstation.

If I were Sun, I would try to sell more hardware and offer more hardware-related services :-):

1. I would try to create a Java-Branded Workstation - just for developers, and place it somewhere prominently, or at least make the existing one more visible. With virtualBox, Ubuntu / openSolaris / Windows this could probably take off. I would actually buy one. I think there are enough Java-enthusiast out there, so that this could pay-off.
   
2. I would offer Glassfish, Grails, Rails on EE, etc. hostings / services / clouds. Sun has a Grid, which is rather a generic solution. But Amazon has EC2 and Google the AppEngine. This is actually strange.
3. Sun servers are not really visible to developers. I would try to change it, and offer some entry point servers to play with. I know many developers building their own systems (I'm one of them), which are actually not that cheap.

The hard work is actually done - I'm missing only few remaining parts like nice online store, straightforward marketing and more visibility.

Posted at 10:03AM Jul 15, 2008 by Adam Bien in Fun  |  Kommentare[11]

 Subscribe in a reader

Last year there were too many registrations - so I had to repeat the workshop next day. I actually didn't expected that much interests on Java EE 5, EJB 3 and JSF (class evaluations are available here). This year the workshop will start, with what the last ended - the design of boundary between the presentation and business tier. The students asked me about this topic - and here we go :-). I intend to introduce Domain Driven Design in contrary to SOA together with JSF, EJB 3, Wicket, GWT and Google's Guice and concentrate especially on the boundary between the two layers. I would like to highlight the issues and challenges like eager / lazy loading, versioning, detachment caching, data binding, data transportation between layers, working with WYSIWYG editors and transactions.

I will explain the idioms with lots of code and some slides - the same procedure as last year :-). I really looking forward to this event. The location is beatiful (Zurich Lake, in the near of sail boat harbor), well organized with really nice students. I will give this workshop in German - however if you prefer English - come to San Jose - to the U.S. JAX :-).

Posted at 05:31PM Jul 13, 2008 by Adam Bien in Events  |  Kommentare[2]

 Subscribe in a reader