...Last week, we launched a replacement for our Ruby-on-Rails front-end: a Java server we call Blender. We are pleased to announce that this change has produced a 3x drop in search latencies and will enable us to rapidly iterate on search features in the coming months...

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.

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.

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. [...]

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

--KentBeck

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.

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) :-)

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.

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...

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...