Adam Bien's Weblog

Main | Next page »

Monday Mar 15, 2010

Legally Starting Threads/Synchronizing EJBs - Hell Or Heaven

EJB spec does not allow starting and managing threads ...in general. With @Singleton you can do whatever you want even:

With Bean Managed Concurrency demarcation, the container allows full concurrent access to the Singleton bean instance. It is the responsibility of the bean developer to guard its state as necessary against synchronization errors due to concurrent access. The bean developer is permitted to use the Java language level synchronization primitives such as synchronized and volatile for this purpose. [EJB 3.1 spec, page 111]

You only need to apply an additional annotation on a @Singleton and do whatever you want - at least synchronization-wise:


@Singleton
@ConcurrencyManagement(ConcurrencyManagementType.BEAN)
public class InefficientHelloWorld {
    //AtomicInteger would be a lot better.
    private static volatile int counter = 0; 
    //synchronized just for demo purposes, o.k with CMT.Bean.
    public synchronized void sayHello(){
        new Thread(new Runnable() {    //still not allowed - but it works
            public void run() {
			  //out.println is not a best practice either...
                System.out.println("Hello World: " + counter++);

            }
        }).start();
    }
}

In the majority of all cases it is better to use just @Stateless beans and just let the container manage threads and synchronization for you.
@Asynchronous is far better and easier to use , than the example above.
The "working" example was pushed into http://kenai.com/projects/javaee-patterns/. The name of the project is "BeanManagedConcurrency".

Starting and managing threads in the application code is hard to implement, monitor and debug - it is by no means a best practice.

[See Lightweight Asynchronous Facade pattern, page 65 in "Real World Java EE Patterns Rethinking Best Practices" book for more in-depth discussion]

Posted at 12:07PM Mar 15, 2010 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Kommentare[11]

[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices

Sunday Mar 14, 2010

Free Java EE 6 Workshop - For Students In Bonn

I will give a workshop - almost without slides, spending the majority of the (3h) time in the IDE (NetBeans this time, IntelliJ is also possible, but we will have definitely no time for the installation of all the nice Eclipse plugins :-)). It seems like this workshop is free for students.

We will have 3h for develop something in Java EE 6 - its more than enough. We will need 10 minutes to install the IDE, application server and database (double-click on the installation of NetBeans 6.8 "Java Edition":-)) - then we can start. So I will probably, in addition to the abstract, implement and explain testing, mocking, integration tests, batch processing, CDI, JMS and probably connectors and refine the JSF 2 view.

Also looking forward to the SDC conference in gothenburg - unfortunately I can only spend few hours in this nice city. There will be no time for a porter...

Posted at 10:29PM Mar 14, 2010 by Adam Bien in Events | Kommentare[2]

[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices

Thursday Mar 11, 2010

Modules, Cycles, Unwanted Friends - The Modularity Challenges In Enterprise Projects

Building modules and components is not that hard. You "only" have to encapsulate the internal component implementation and expose a clean and easy to use interface. ...at least on paper. In practice you will be confronted with the following challenges in the early iterations:

The external interface is too coarse and far less interesting for internal reuse, than you had thought.
The interesting things are residing inside the component. They are, however, well encapsulated and not accessible from the outside.

Example: you have two independent components; customermgmt and address / geo-location service. The module customermgmt exposes CRUD services and the address component extensive search capabilities. So far the world is perfect.
Now: a customer has an address - how to model that? The external, customer contract will have to reference the address somehow. That is often modeled as a direct relation between DTOs (just a getter). The external view of the customer component is now dependent on the address component. The implementation is still independent.

The relation between the customer and the address has to be persisted somehow. And now the trouble starts. Now the implementation of the customer component is dependent on the address component - because of direct (JPA) link between both modules. Now the internal implementation *and* the component contract are dependent on each other.

You are using JPA 1.0 - and your database experts just don't want to introduce an additional mapping table between the customer and the address. So you have to model a bi-directional relation between the customer entity and the address (introducing a back-link with a mappedBy attribute). Now you get a bidirectional dependency between the implementation of your component - the external dependency of the customer can remain unidirectionally dependent on the address. This is only true if you are using DTOs.

So you get two components which should be independent of each others, but are actually tightly coupled. Your modules have to expose everything - if you are using Java EE 6 - the DTOs and JPA-entities are dependent of each other - probably only the very thin boundary may remain independent. In practice you will get e.g. an invoice module in addition, which will be dependent on both the customer and the address....

You can do the following to "improve" the situation:

Factor out all entities into a common package. Often called "domain", "model" or even "common". Such a common package is not cohesive (it contains multiple business concepts) and also not very good to maintain (the generic names have nothing to do with the actual business). This approach looks great ...on paper.
Drop JPA-relations and introduce proxy-objects, which contain the ID and can be resolved on demand. This will significantly increase the amount of code and will hit your performance. You will be not able to use joins...
Allow bidirectional friend-dependencies between modules. In that case it will be hard to introduce a framework like OSGi, jigsaw or something else. But you can still put all "business components" into few modules. Then the real benefit of OSGi, Jigsaw etc is questionable.
Remove OR-mappers and go with "plain" JDBC. Let the DB handle the dependencies for you. In most cases this is not really a maintainable option.

Dependencies between persistent objects from different modules are practically not existing in other domains like IDEs, servers or plugins, but are the standard case in enterprise projects.
So, you shouldn't kill any OSGi project - you should implement some typical use cases (PoCs) with modularity solution of your choice before the project really starts. This is actually independent of any framework like OSGi, jigsaw or EMS (esoteric module system) :-).

[See also "Real World Java EE Patterns, Rethinking Best Practices" book, Page 267, (Monolithic or Loosely Coupled?) for more in-depth discussion]

Posted at 11:32AM Mar 11, 2010 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Kommentare[4]

[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices

Monday Mar 08, 2010

How To Kill An OSGi Project - With 10 Questions

OSGi focusses on modularity and it is right now (future may change it) the only viable way to split your application into modules with well-defined dependencies. It solves, however, "only" the technical problem - which is actually relatively easy. Before you going to introduce OSGi into your project, answer the following questions:

What is your versioning scheme for modules(bundles)? Do you care about minor versions, major versions etc?
Whats your scm strategy - do you plan to open and maintain a branch for every version of a module? How many branches do you plan to maintain? (with svn? :-))
How many versioned modules will be active at the same time in production?
How the system is going to be tested? Each module and all the combination of modules. Every version will increase the complexity significantly.
What is your release-management strategy? Do you really plan to provide customer-specific module combinations? What is your bug-fixing / patch strategy (trunk, branch)?
Do you really want to replace modules in running system? If it is a serverside system - what happens with in-flight transactions?
If it is an Eclipse-RCP application - are you even allowed to expose the plugins to the end-user? (in the majority of my projects, we had to disable the update manager in production :-))
What is your software distribution system - many companies have already a software-distribution system in place. Often not only the application, but also the JVM are packaged into one binary file and entirely installed. Incremental updates are often impossible.
What is exactly the contract between the modules? Only a Java-Interface? If so - what to do with direct relations between JPA-entities. If you disallow direct JPA-relations - you will probably see a huge "domain" package with all domain objects inside it. You will need to provide "friend" relations between modules as well.
Is maven the canonical representation of modules, OSGi, or both? A single representation would be the best. Will maven module versions be reflected in the OSGi bundle versions?

The major OSGi-challenge is not the technology, rather than the governance of your modules and bundles. The problem is very similar to SOA.

For most enterprise applications you will get only one variant of your business logic, or even UI - so you will end up with modules, which will probably never be replaced. Because of additional complexity - you will probably test and deliver the whole system at once.

If you are building an IDE, platform or a server - governance, modularization and versioning are a major part of your problem domain / functional requirements. You will have to solve that anyway. It is far more likely, that someone will have to install a new driver to an application server, or even maintain different versions of the driver at the same time. IDEs without plugins are also extremely rare.

Replacing an algorithm in a business application is far more uncommon - often even not allowed. Its just crazy to introduce a modularization solution and then not use it.

[See also "Real World Java EE Patterns, Rethinking Best Practices" book, Page 253, (Premature Encapsulation Is the Root of All Evil) for more in-depth discussion]

Posted at 10:28AM Mar 08, 2010 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Kommentare[12]

[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices

Sunday Mar 07, 2010

Killing Some Bloat in Gothenburg - With Java EE 6

I will spend few hours in Gothenburg at the SDC 2010 conference and give a talk with the title "Lightweight Killer Apps with Nothing But Vanilla Java EE 6". I'm really curious whether my first slide will look familiar to you - people outside Sweden are thinking, that it is the Golden Gate Bridge, what is entirely wrong.

I will have some time after the session. So if you have some questions, want to discuss, or hack some code - just ping me. I planned to spend more time in Gothenburg - a really nice city. Because of the project (over)load, probably caused by the general Java EE 6 take off :-), - I will only spend few hours.

Posted at 10:28PM Mar 07, 2010 by Adam Bien in Events | Kommentare[0]

[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices

Saturday Mar 06, 2010

What Is www.sun.com/ponytails/ ?

An interesting URL: http://www.sun.com/ponytails. It gets resolved to: http://www.sun.com/software/opensource/. Now the question - why ponytail? :-)

Posted at 12:51PM Mar 06, 2010 by Adam Bien in Fun | Kommentare[4]

[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices

Friday Mar 05, 2010

Best of 2009 - Most Popular Posts (Dead DAOs, Bloat Without EJBs, Java EE vs. Spring, VOs vs. DTOs)

January: In The Age Of DRYness - Do We Really Need Naming Conventions For Interfaces? (11288 Views)
February: DAOs Aren't Dead - But They Either Collapsed Or Disappeared (9565 reads)
March: What You Can Build In 50 Minutes With Java EE 5/6? (25942 views)
April: Lean service architectures with Java EE 6 - And EJB 3 in particular (4304 views)
May: Netbeans 6.7 Beta + Maven = Heaven (more than promising) (11697 views)
June: Real World Java EE Patterns - Rethinking Best Practices Book And Project (15456 views)
July: Lean Java EE 6 Without Spring And Spring 3.0 In Java EE 6 World: Summary and Conclusion (eJug Session) (16203 views)
August: Value Object vs. Data Transfer Object (VO vs. DTO) (15928 views)
September: Why Oracle Should Continue To Push NetBeans (18974 views)
October: (JSF + JPA) - EJB = Bloat (17436 views)
November: Two Amazing NetBeans 6.8Beta Features (8877 views)
December: Java FX Composer / Designer for NetBeans 6.8 - First Smoke Test (15276 views)

The views above are monthly results - not overall views. The actual number should be much higher. RSS/Atom-Feed results are not even included in this statistic. The daily average ranged from 4.5k - 8k.

The stats for the year 2010 are more than promising. February is already the best month ever. Thanks for reading and especially the constructive 2.5k (!) comments.

Posted at 09:56AM Mar 05, 2010 by Adam Bien in Blog Statistics | Kommentare[0]

[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices

Sunday Feb 28, 2010

Oracle Data Sheet About ...Glassfish

"...Oracle GlassFish Server is part of the Oracle Fusion Middleware application grid portfolio and is ideally suited for applications requiring lightweight infrastructure with the most up-to-date implementation of enterprise Java, Java EE 6, and Java Web services. Oracle GlassFish Server complements Oracle WebLogic Server, which is designed to run the broader portfolio of Oracle Fusion Middleware and large-scale enterprise applications..." Read the whole paper.

Posted at 10:34AM Feb 28, 2010 by Adam Bien in General | Kommentare[2]

[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices

Friday Feb 26, 2010

Jigsaw / JDK 1.7 will be the solution for 80% of the modularization challenges

Jigsaw will come with JDK 1.7 and is now part of the openjdk project and so opensource. Other JDK implementations could simply reuse it.It will become interesting, because:

It will be shipped with every Oracle / Sun JDK 1.7 (at least it was the plan)
Jigsaw will partition JDK 1.7 and will be loaded before most of the rt.jar code. So is already there - no reason to introduce another framework
Its pragmatic: you can split packages across modules. Package splitting isn't a best practice, but makes the incremental modularization of legacy projects a lot easier
Modules are loaded statically - no reloading. This is good enough for the most projects. Its funny - but in most NetBeans RCP / Eclipse RCP projects we had to deactivate the ability to load modules dynamically in production :-). Server operators don't like dynamic behavior either.
It seems like there will be only one classloader, which will load all modules. This will eliminate majority of NoClassDefFoundErrors.
javac will be jigsaw aware - this is a major advantage. Module dependencies should be checked as early as possible - it fits well with the nature of Java.
Jigsaw should increase the classloading performance and significantly reduce the size of the jars and so the deployment

Posted at 11:00AM Feb 26, 2010 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Kommentare[26]

[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices

Monday Feb 22, 2010

Simplest Possible EJB 3.1 Timer - Configured Programmatically

@Singleton @Startup public class PeriodicTimer { @Resource TimerService timerService; @PostConstruct public void initialize(){ ScheduleExpression expression = new ScheduleExpression(); expression.second("*/1").minute("*").hour("*"); timerService.createCalendarTimer(expression); } @Timeout public void execute(){ System.out.println("----Invoked: " + System.currentTimeMillis()); } }

A timer doesn't have to be a singleton - it can be a @Stateless and even a @Stateful bean. The method execute() will be invoked every second after the deployment. The programmatic registration is only an option. You could also use annotations for the timer configuration.

How to compile:

You will need the EJB 3.1 API in the classpath (few kilobytes).

How to deploy:

Just JAR or WAR the interceptor with an EJB and put the archive into e.g: [glassfishv3]\glassfish\domains\domain1\autodeploy

Btw. the initial deployment of the entire WAR took on my machine:


INFO: Loading application ProgrammaticallyCreatedTimer at /ProgrammaticallyCreatedTimer
INFO: ProgrammaticallyCreatedTimer was successfully deployed in 316 milliseconds..

How to use:

Another service can be easily injected to the timer and so invoked periodically:


@Stateless
public class HelloService {
    public String sayHello(){
        return "Hello from control: " + System.currentTimeMillis();
    }
}

And: there is no XML, strange configuration, libraries, additional dependencies needed...You will find the whole executable project (tested with Netbeans 6.8 and Glassfish v3) in: http://kenai.com/projects/javaee-patterns/ [project name: SimpleTimer].

Posted at 09:00AM Feb 22, 2010 by Adam Bien in General | Kommentare[3]

[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices