Thursday, March 22, 2007

Java OpenSource Components

Components I am currently using:

Lucene - indexer & search engine. There is a couple of commercial indexers that will work a bit faster, but Lucene does the trick very well. I would give it 8 out of 10.

HSQLDB - (aka Hypersonic) Java RDBMS, really easy to embed. If you want to provide zero admin configuration, check it out. There are some newer projects, even provided by Apache Foundation, but I am too lazy to try. Don't expect it to work very well with huge amount of tables (over 500) and in volatile environment (if indexes and columns are created on the fly, while there is a number of transactions running). For usual CRUD, even with heavy load, it works nicely.

Rhino - very useful, if you need to provide high level scripting for your application (e.g. you want field engineers to customize your solution). It will give you JavaScript access to all your server calls - just don't think of this JavaScript in terms of browsers and their DOM model.

Suigeneris DIFF - text comparison tool (diff, in short). Just works.

iBATIS - if Hibernate is overkill, not mentioning EJBs , iBATIS is your way to implement efficient DAO. Transactions, lazy loading, SQL code separaion from your Java sources.

ActiveMQ - durable messaging. Durable in terms that if your server goes down and up, the message queus will keep their data and order.

Tomcat - no comments. I guess it is harder to get around it than to try it out.

In evaluation

Apache Solr - indexer/searcher for structured data (i.e. XML).
Lius - indexer/searcher for most standard data formats: Office, PDF, XML etc. Just released as 1.0
Both of them are Lucene-based.
JackRabbit - JCR API ref implementation (content repository).

So far not in use:
- good concept, very useful, but overkill for many smaller projects (by small I mean number and level of interdependency of separate components)
AXIS2 - lots of good ideas, but difficult to embed and a bit of a monster (own substructure of class loaders, complicated packaging). AXIS 1.4 works for me quite well, for simple embedded web services. JAX-WS 2.0 didn't work out at all, again because of embeddability into own web applications. However, if you have a full J2EE server, it is the way to go, of course.

Monday, March 05, 2007

Ok, Tomcat 6 is out and stable and contains new type of servlet called Comet (more info on Tomcat’s version is here), new Jetty has a similar mechanism (another open source servlet container that is usually considered to have the fastest engine when benchmarked; however, the speed comes with a price tag of portability). To understand, what is going on I was digging through the net for some time now.

Java has its java.nio since 1.4 – New I/O with non-blocking streams. It is possible to create non-blocking sockets with this API too. A tutorial I was using to understand the architecture is here: This is the best tutorial I have found, but still it was a bit heavy on my brain :)

To speedup servlet engine by using NIO sockets, Jetty developers came up with continuations: - a way to suspend current HTTP request thread and free the server thread for other clients. In ‘normal’ circumstances, i.e. in ‘old’ web development where user clicks on URL and gets the page rendered by the servlet, there is no need for suspending the thread – why make user wait? Not so with AJAX or HTTP 1.1 KeepAlive – here, client-side browser scripts want to have the connection open at all times to pull the newest data as soon as it is available: chat room engine waits on socket stream to receive new messages; input completion engine (e.g. considers it too costly to open connection every time user types a letter to get suggestions etc. In general there is a shift in web server development strategy to move from request/response paradigm to endless asynchronous messaging queue.

Now, this whole NIO doesn’t really fit into Servlet API standard:

After reading all of these I feel like I am at the square one and have no clear idea as to how to write ‘clean’ web application. All the new stuff creates a huge mess of interwoven technologies, which are quite difficult to sort out by anyone looking at the ‘new style’ servlet code. And JSP 2.1 is not helping by introducing new Unified Expression Language. Are we heading towards faster web app servers and slower, disoriented programmers with constant headaches? For me, I decided to stick to less “cutting edge”, but easier to read and maintain old Servlet API standard, for now.