Adam Bien's Weblog

far better than expected. The landscape:

1. Java EE 5 is already supported by 14 (all major) application servers.
2. Java EE 6 is already supported by Glassfish 3 and partially by JBoss 6.0 and Geronimo.

Posted at 09:00AM Nov 16, 2009 by Adam Bien in Productive Java EE - Rethinking Best Practices  |  Kommentare[4]

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

1. The functional units are already independent or loosely coupled in the target domain (from the conceptual perspective). 
2. The functional requirements allow asynchronous communication between the components. Even better: they are already modeled as asynchronous processes.
3. The service component, which offers the services, is likely to change, what would break the "client" component.
4. The service component is not technology or even vendor agnostic. Direct communication with such service component would "pollute" all clients. Encapsulation is a must in this case.
5. Both components have different release cycles. Service component is likely to change, but the client component cannot be re-installed or rolled-out.
6. Both components are going to be developed by different teams, or even some parts outsourced to other companies.
7. An average RFE will cause only local changes in a single component and the decoupling / indirection will help you to isolate those changes.
8. There are already different algorithms available for a given functionality or use case (see e.g. the Strategy Pattern).
9. You are building an API or platform, which is going to be used by other applications.
10. Obvious: the UI should be always decoupled from the business logic realization. Multiple UIs (e.g. JSF, RIA, IPhone) are very likely - also in enterprise environment.

Posted at 09:00AM Aug 27, 2009 by Adam Bien in Productive Java EE - Rethinking Best Practices  |  Kommentare[6]

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

JBoss 5.1.0 GA comes with a visual administration console, which seems to be based on JSF 1.2 with RichFaces and Seam. You can reach the console under the following URL: http://localhost:8080/admin-console/. User name and password are both admin (unlike Glassfish, where the password is adminadmin :-)). JBoss 5.1.0 installation was very smooth: download, extract and start.

First impressions: 

1. The admin console looks nice and clean
2. The most important resources like JDBC / JMS / EJB 2 and 3 applications are accessible.
3. You can start and stop services applications and modules (ejb-jars) directly from the admin console
4. Basic metrics for application server, resources and applications are available:

   VM Free Memory	101.6MB	The amount of free memory for the JVM this app server instance is running on
   JVM Max Memory	490.7MB	The amount of max memory for the JVM this app server instance is running on
   JVM Total Memory	490.7MB	The amount of total memory for the JVM this app server instance is running on
   Total Transactions	0	Total number of transactions since last restart
   Transactions Committed	0	Number of transactions commited since last restart
   Transactions Rolledback	0	Number of transactions commited since last restart

5. The administration console is fast and responsive.
6. I tried, however, to create a new JMS destination via the console and got the following error (will have to investigate the cause):
    Failed to add Resource (see app server log for additional details): java.lang.RuntimeException:Failed to process template. -> java.lang.RuntimeException:java.io.FileNotFoundException: /Users/abien/work/servers/jboss-5.1.0.GA/server/default/deploy/jms/hugo-service.xml (No such file or directory) -> java.io.FileNotFoundException:/Users/abien/work/servers/jboss-5.1.0.GA/server/default/deploy/jms/hugo-service.xml (No such file or directory) 

1.  GF help system and documentation is really well integrated into the console.
2. With GF v2 you can easily manage your JVM settings.
3. Callflow (a tree-like monitoring preview) is useful for monitoring, the other metrics are also finer.
4. You can access and filter log files directly from the console.
5. Custom JMX-monitoring can be directly configured from the admin console.
6. You can setup a cluster directly from the console.
7. The synergy between the domain.xml (configuration file), the command line interface asadmin (could be considered as a configuration DSL) and the visual console is unique (I'm planning to demos some features at the CommunityOne West)
8. [...]

Posted at 10:29AM May 28, 2009 by Adam Bien in Productive Java EE - Rethinking Best Practices  |  Kommentare[14]

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

"just as you can write fortran in any language,you can run a waterfall or codenfix project with any development process"

--KentBeck

Posted at 09:00AM May 15, 2009 by Adam Bien in Productive Java EE - Rethinking Best Practices  |  Kommentare[0]

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

My article about Java EE 6, and EJB 3.X in particular was published at JavaWorld. This article is one of the reasons, why this blog became so fluffy - I don't like duplication :-). The second part is almost completed.

Posted at 09:00AM Apr 15, 2009 by Adam Bien in Productive Java EE - Rethinking Best Practices  |  Kommentare[5]

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

To define a perfect architecture you should:

1. Define the intension of every modeled arrow, box, layer or artifact in a wiki. Try to "sell it" by initiate an open discussion with the stakeholders (developers, testers, operators etc.). Be active and invite them for participation. It is easier to create an architecture, then to finally "sell it".
   
2. Build a POC for every such an artifact. There should be a 1:1 mapping between the conceptional word of bubbles, arrows and boxes and the source code. If there isn't you aren't done yet.
   
3. Go through every artifact and think about whether it is really needed. Ask the question over and over again: "Do we really need it?". If there is no good answer why it exist - just remove it.

And remember: Bubbles don't crash.

It was hard to tweet about it (>140 characters) :-)

Posted at 09:00AM Apr 02, 2009 by Adam Bien in Productive Java EE - Rethinking Best Practices  |  Kommentare[1]

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

After the installation and launch of the Performance Monitor (see doc and some resources) I was somehow disappointed - it looks like VisualVM with a nice splash screen. Performance Monitor (PM) recognized my running Glassfish v2.1 instance - double-clicking on the instance opened a monitor-view - identical to the visualvm with CPU, heap, permgenspace, threads, loaded classes etc. The interesting part begins after connecting to GF using the JMX connection (e.g. localhost:8686).

It opens a tree-like view with the server as root node. You can activate the monitoring here for the following subsystems: ConnectorConnectionPool, ConnectorService, EJBContainer, HTTPService, JDBCConnectionPool, JMSService, JVM, ORB, ThreadPool, TransactionService, WebContainer. 

Setting the monitoring configuration to "Low" should be enough. After activating the configuration and waiting for few seconds, you should see the nodes appearing under the root.

Now you get the opportunity to visualize the behavior of connection pools, thread pools, JMS connection factories, WebServices etc. and search for possible bottlenecks. This information is invaluable for every load and performance test - it reminds me of the LoadRunner's monitoring capabilities. All the information is also available through the JConsole - but is lot harder to analyze and corelate.

What I miss, hovewer, is the detail view of EJB behavior like method invocation count, slowest, fastest methods etc. This information is already available in the Call Flow monitoring, so it should be somehow accessible. I wasn't able to find monitoring information for a single destination as well, only for the corresponding ConnectionFactory.

Sun Glassfish Enterprise Manager Performance Monitor (SGEMPM a nice name :-)) is a commercial extension, only available with support. From my perspective its a fair decision to make the SGEMPF commercial. If you have no money but time, you can go with JConsole and try to correlate the information manually. And if you want to save time, you can buy support and get the tool for free :-). SGEMPM is also able to monitor clusters - which makes it interesting for "mission critical" applications.

Posted at 09:00AM Apr 01, 2009 by Adam Bien in Productive Java EE - Rethinking Best Practices  |  Kommentare[3]

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

EJB 3.0 are part of the majority of the mainstream application servers. Although EJB 3.0 are already very effient, lean and can be hardly further simplified - this is actually not the issue. You can save more and more money in the maintenance phase of an application. Although the economy tends to move in the direction of opensource application servers, serious applications always run on officially supported (opensource) application servers.

No one dares, mostly because of political reasons, to run critical software on unsupported platforms, regardles how good the own IT-department really is. ...and you have to spend some money on it. In general you get the support for EJBs included - it comes "out of the box". If you, on the other hand, deploying frameworks like Guice, Hivemind, Nanocontainer, Spring or even Seam (not on JBoss), you will have to think about the support for those frameworks as well. Such a mix is always challenging - at least the reproduction for a support case. In long term the cheapest possible solution will be the use of plain Java EE 5 containers, or a full stack alternatives like e.g. a transactional OSGI container or SpringSource dmServer. Running a full Java EE stack and an alternative on one box is just too expensive to be officially supported...

Posted at 09:00AM Mar 26, 2009 by Adam Bien in Productive Java EE - Rethinking Best Practices  |  Kommentare[6]

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

I'm often asked about the list of Java EE 5 compatible applicationservers. Here is the complete list of officially certified servers. But the actual number of servers should be even greater - even Spring supports EJB 3.0...

Posted at 09:00AM Mar 25, 2009 by Adam Bien in Productive Java EE - Rethinking Best Practices  |  Kommentare[3]

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

Since the advent of EJB 3.X I don't use the Local/Remote naming schemes for business interfaces any more. The EJB client is only interested in the functionality and not the distribution or other infrastructural settings. The business interface is therefore just a POJI - without any dependency on the EJB API or infrastructure:

public interface CrudService {

}

The EJB implements the interface and exposes it with the @Local annotation. 

@Stateless
@Local(CrudService.class)
@TransactionAttribute(TransactionAttributeType.MANDATORY)
public class CrudServiceBean implements CrudService {
}

I actually thinking about getting rid off the suffix Bean as well. It would be much better to emphasize the actualy responsibility and name after it e.g. a JPACrudService. It is already annotated with the @Stateless annotation - so it is obviously a Bean. In my opinion interface naming schemes are unnecessary in general.

Posted at 02:43PM Mar 17, 2009 by Adam Bien in Productive Java EE - Rethinking Best Practices  |  Kommentare[2]

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