...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......To ensure a high quality of service while introducing Blender into our system (=twitter.com), we are using the old Ruby on Rails front-end servers as proxies for routing thrift requests to our Blender cluster. Using the old front-end servers as proxies allows us to provide a consistent user experience while making significant changes to the underlying technology. In the next phase of our deploy, we will eliminate Ruby on Rails entirely, connecting users directly to Blender and potentially reducing latencies even further... -@twittersearch From http://engineering.twitter.com/2011/04/twitter-search-is-now-3x-faster_1656.html Btw. I do not believe, that Java (EE) will kill Ruby on Rails either. Just use the right tool for the job (and Java for highly scalable apps)...
far better than expected. The landscape:
- Java EE 5 is already supported by 14 (all major) application servers.
- Java EE 6 is already supported by Glassfish 3 and partially by JBoss 6.0 and Geronimo.
The adoption is harder to estimate - but it seems like Java EE 5 (6 is too early) and EJB 3 are gaining momentum. The w-jax conference is over - it was interesting to observe some indicators:
- The first time ever there was an EJB 3 / Java EE 6 day. More important: it was very well attended.
- Our EJB 3 / Java EE 6 table during the ballroom night (a kind of openspace) was (over)crowded. We already thought about occupying the JRuby table near us :-). All attendees had already EJB 3 experience. The participants introduced interesting projects from the biometric area, over health care system, to route planing and automation. This really surprised me.
- Several projects are going to migrate their existing EJB 2 infrastructure to EJB 3. I had two conversations about migration from Spring to EJB 3. The reasons, however, were strategic and not technology driven.
- Speakers signalized their interests as well. We had a really nice hall conversations about the EJB 3 programming model and its lightweight nature. I didn't expected it either. Even a Tomcat committer is starting to investigate EJB 3 :-).
- My interactive hacking session (60 minutes - with Java EE 6) was attended by ~ 200 people in a room with 180 capacity :-). Btw. the average deployment time took <10ms (Glassfishv3b70 and NetBeans 6.8beta). This caused some interesting discussions afterwards.
- At the very last day - I gave a workshop with the title "Java EE Patterns - Rethinking Best Practices" with 55 attendees (a new record). The majority of the attendees had already EJB 3 / Java EE 5 experience. I got really good questions about modularization, transactions, caching and performance during the day. My general observation is: developers, who already used EJB 3, really like it.
See also my tweets. The w-jax conference this year was very well attended (subjectively: more than last year). The conference was well organized with excellent food and location (Westin Grand Hotel in Munich...).
I also recognize growing interests in EJB 3 / Java EE topics in this blog. EJB 3 / Java EE 6 topics are very popular.
- The functional units are already independent or loosely coupled in the target domain (from the conceptual perspective).
- The functional requirements allow asynchronous communication between the components. Even better: they are already modeled as asynchronous processes.
- The service component, which offers the services, is likely to change, what would break the "client" component.
- 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.
- Both components have different release cycles. Service component is likely to change, but the client component cannot be re-installed or rolled-out.
- Both components are going to be developed by different teams, or even some parts outsourced to other companies.
- An average RFE will cause only local changes in a single component and the decoupling / indirection will help you to isolate those changes.
- There are already different algorithms available for a given functionality or use case (see e.g. the Strategy Pattern).
- You are building an API or platform, which is going to be used by other applications.
- 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.
Decoupling or modularization do cause additional coding / conceptual / auditing (e.g. metrics) effort. The reason / intention for decoupling or modularization has to be clearly documented, otherwise the resulting code can be hard to understand and, in long term, to maintain.
[Data Transfer Objects are often introduced to increase decoupling, see page 153 in "Real World Java EE Patterns - Rethinking Best Practices" and Premature Encapsulation Is the Root of All Evil, Page 253]
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.
- The admin console looks nice and clean
- The most important resources like JDBC / JMS / EJB 2 and 3 applications are accessible.
- You can start and stop services applications and modules (ejb-jars) directly from the admin console
- 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
- The administration console is fast and responsive.
- 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)
- GF help system and documentation is really well integrated into the console.
- With GF v2 you can easily manage your JVM settings.
- Callflow (a tree-like monitoring preview) is useful for monitoring, the other metrics are also finer.
- You can access and filter log files directly from the console.
- Custom JMX-monitoring can be directly configured from the admin console.
- You can setup a cluster directly from the console.
- 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)
JBoss 5.1.0 is on the right track. The current admin-console is lot better, than the <5.1 alternatives (jmx-console, web-console), which even were not password protected. I hope JBoss-guys will keep improving the admin-console, then Glassfish v3 will get a really serious competitor :-).
I'm really curious about the interoperability - will try to deploy some Java EE 5 applications from GF v2 to JBoss 5.1.0.
"just as you can write fortran in any language,you can run a waterfall or codenfix project with any development process"
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:
- 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".
- 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.
- 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...