Technologies for JAVA Web Application

Hello Friends,

Recently in one of the interview, interviewer asked me “Have you ever hands on Mule, ActiveMQ , Vaadin , MongoDB, CouchDB, Neo4J, GWT ?”,  i am speechless, because among all of these,  some are the word which i had listen first time in my life, and i was just left out that interview  and start googling these all tachnology, why it uses? Where is to be used? When to be used? And How to be used?

So, here i will be shared my experience with you of that technologies and some quick overview of that.

Neo4j: NOSQL for the Enterprise

Neo4j is an open-source graph database, implemented in Java. The developers describe Neo4j as “embedded, disk-based, fully transactional Java persistence engine that stores data structured in graphs rather than in tables”.

Neo4j is a high-performance, NOSQL graph database with all the features of a mature and robust database. The programmer works with an object-oriented, flexible network structure rather than with strict and static tables — yet enjoys all the benefits of a fully transactional, enterprise-strength database. For many applications, Neo4j offers performance improvements on the order of 1000x or more compared to relational DBs.

Wait, what is Neo4j?

Neo4j is a graph database, that is, it stores data as nodes and relationships. Both nodes and relationships can hold properties in a key/value fashion.

You can navigate the structure either by following the relationships or use declarative traverser features to get to the data you want.

Handling complexity

Most applications will not only have to scale to a huge volumes, but also scale to the complexity of the domain at hand. Typically, there may be many interconnected entities and optional properties. Even simple domains can be complex to handle because of the queries you want to run on them, for example to find paths. Two coding examples are the social network example (partial Ruby implementation) and the Neo4j IMDB example (Ruby variation of the code). For more examples of different domains modeled in a graph database, visit the Domain Modeling Gallery.

Storing objects

The common domain implementation pattern when using Neo4j is to let the domain objects wrap a node, and store the state of the entity in the node properties. To relieve you from the boilerplate code needed for this, you can use a framework like jo4neo (intro, blog posts), where you use annotations to declare properties and relationships, but still have the full power of the graph database available for deep traversals and other graphy stuff. Here’s a code sample showing jo4neo in action:

public class Person {
  //used by jo4neo
  transient Nodeid node;
  //simple property
  @neo String firstName;
  //helps you store a java.util.Date to neo4j
  @neo Date date;
  // jo4neo will index for you
  @neo(index=true) String email;
  // many to many relation
  @neo Collection<role> roles;

  /* normal class oriented
  * programming stuff goes here

Another way to persist objects is by using the neo4j.rb Neo4j wrapper for Ruby. Time for a few lines of sample code again:

require "rubygems"
require "neo4j"

class Person
  include Neo4j::NodeMixin
  # define Neo4j properties
  property :name, :salary, :age, :country

  # define an one way relationship to any other node
  has_n :friends

  # adds a Lucene index on the following properties
  index :name, :salary, :age, :country


Of course you want a RESTful API in front of the graph database as well. There’s been plenty of work going on in that area and here are some options:

  • The neo4j.rb Ruby bindings comes with a REST extension.
  • The neo4jr-simple Ruby wrapper has the neo4jr-social example project, which exposes social network data over a REST API.
  • Similarly, the Scala bindings has a companion example project which will show you how to set up a project exposing your data over REST.
  • Last but not least, Jim Webber has joined up with the core Neo4j team to create a kick-ass REST API. The current code base is only in the laboratory but a lot of people are already kicking its tires.

Language bindings

The Neo4j graph engine is written in Java, so you can easily add the jar file and start using the simple and minimalistic API right away. Your first stop should be the Getting started guide, or if you want to add a package of useful add-on components to the mix, go for Getting started with Apoc. Other language bindings:


Work is being done on using Neo4j as backend of different frameworks. Follow the links to get more information!


  • Shell: a command-line shell for browsing the graph and manipulate it.
  • Neoclipse: Eclipse plugin (and standalone application) for Neo4j. Visual interface to browse and edit the graph.
  • Batch inserter: tool to bulk upload big datasets quickly.
  • Online backup: performs backup of a running Neo4j instance.

Query languages

Beyond using Neo4j programmatically, you can also issue queries using a query language. These are the supported options at the moment:

  • SPARQL: Neo4j can be used as a triple- or quadstore, and has SAIL and SPARQL implementations. Go to the components site to find out more about the related components.
  • Gremlin: a graph-based programming-language with different backend implementations in the works as well as a supporting toolset.


Apache CouchDB, commonly referred to as CouchDB, is an open source document-oriented database written mostly in the Erlang programming language. It is part of the NoSQL group of data stores and is designed for local replication and to scale horizontally across a wide range of devices.

What CouchDB is

  • A document database server, accessible via a RESTful JSON API.
  • Ad-hoc and schema-free with a flat address space.
  • Distributed, featuring robust, incremental replication with bi-directional conflict detection and management.
  • Query-able and index-able, featuring a table oriented reporting engine that uses JavaScript as a query language.

What it is Not

  • A relational database.
  • A replacement for relational databases.
  • An object-oriented database. Or more specifically, meant to function as a seamless persistence layer for an OO programming language.

CouchDB is most similar to other document stores like Riak, MongoDB and Lotus Notes. It is not a relational database management system. Instead of storing data in rows and columns, the database manages a collection of JSON documents. The documents in a collection need not share a schema, but retain query abilities via views. Views are defined with aggregate functions and filters are computed in parallel, much like MapReduce.

Views are generally stored in the database and their indexes updated continuously, although queries may introduce temporary views. CouchDB supports a view system using external socket servers and a JSON-based protocol. As a consequence, view servers have been developed in a variety of languages.


  • Document Storage

CouchDB stores documents in their entirety. You can think of a document as one or more field/value pairs expressed as JSON. Field values can be simple things like strings, numbers, or dates. But you can also use ordered lists and associative maps. Every document in a CouchDB database has a unique id and there is no required document schema.

  •  ACID Semantics

Like many relational database engines, CouchDB provides ACID semantics. It does this by implementing a form of Multi-Version Concurrency Control (MVCC) not unlike InnoDB or Oracle. That means CouchDB can handle a high volume of concurrent readers and writers without conflict.

  •  Map/Reduce Views and Indexes

To provide some structure to the data stored in CouchDB, you can develop views that are similar to their relational database counterparts. In CouchDB, each view is constructed by a JavaScript function (server-side JavaScript by using CommonJS and SpiderMonkey) that acts as the Map half of a map/reduce operation. The function takes a document and transforms it into a single value which it returns. The logic in your JavaScript functions can be arbitrarily complex. Since computing a view over a large database can be an expensive operation, CouchDB can index views and keep those indexes updated as documents are added, removed, or updated. This provides a very powerful indexing mechanism that grants unprecedented control compared to most databases.

  • Distributed Architecture with Replication

CouchDB was designed with bi-direction replication (or synchronization) and off-line operation in mind. That means multiple replicas can have their own copies of the same data, modify it, and then sync those changes at a later time. The biggest gotcha typically associated with this level of flexibility is conflicts.


CouchDB treats all stored items (there are others besides documents) as a resource. All items have a unique URI that gets exposed via HTTP. REST uses the HTTP methods POST, GET, PUT and DELETE for the four basic CRUD (Create, Read, Update, Delete) operations on all resources. HTTP is widely understood, interoperable, scalable and proven technology. A lot of tools, software and hardware, are available to do things with HTTP like caching, proxying and load balancing.

  • Eventual Consistency

According to the CAP theorem it is impossible for a distributed system to simultaneously provide consistency, availability and partition tolerance guarantees. A distributed system can satisfy any two of these guarantees at the same time, but not all three. CouchDB guarantees eventual consistency to be able to provide both availability and partition tolerance.


MongoDB (from “humongous”) is an open source document-oriented NoSQL database system written in the C++ programming language. It manages collections of BSON documents.

MongoDB features:

  • Ad hoc queries

In MongoDB, any field can be queried at any time. MongoDB supports range queries, regular expression searches, and other special types of queries in addition to exactly matching fields. Queries can also include user-defined JavaScript functions (if the function returns true, the document matches).

Queries can return specific fields of documents (instead of the entire document), as well as sorting, skipping, and limiting results. Queries can “reach into” embedded objects and arrays.

  • Indexing

Indexes in MongoDB are conceptually similar to those in RDBMSes like MySQL. Any field in a MongoDB document can be indexed.

Secondary indexes are also available, including single-key, compound, unique, non-unique, and geospatial indexes. Nested fields (as described above in the ad hoc query section) can also be indexed and indexing an array type will index each element of the array.

MongoDB’s query optimizer will try a number of different query plans when a query is run and select the fastest, periodically resampling. Developers can see the index being used with the `explain` function and choose a different index with the `hint` function.

Indexes can be created or removed at any time.

  • Aggregation

In addition to ad hoc queries, MapReduce can be used for batch processing of data and aggregation operations. In version 2.1, the current development release of MongoDB, a new aggregation framework is available. This framework enables users to obtain the kind of results SQL group-by is used for, without having to write custom JavaScript.

  • File storage

The software implements a protocol called GridFS that is used to store and retrieve files from the database. This file storage mechanism has been used in plugins for NGINX and lighttpd.

  • Server-side JavaScript execution

JavaScript is the lingua franca of MongoDB and can be used in queries, aggregation functions (such as MapReduce), and sent directly to the database to be executed.

Example of JavaScript in a query:

>{$where : function() { return this.x == this.y; }})

Example of code sent to the database to be executed:

> db.eval(function(name) { return “Hello, “+name; }, [“Joe”])

This returns “Hello, Joe”.

JavaScript variables can also be stored in the database and used by any other JavaScript as a global variable. Any legal JavaScript type, including functions and objects, can be stored in MongoDB so that JavaScript can be used to write “stored procedures.”

  • Capped collections

MongoDB supports fixed-size collections called capped collections. A capped collection is created with a set size and, optionally, number of elements. Capped collections are the only type of collection that maintains insertion order: once the specified size has been reached, a capped collection behaves like a circular queue.

A special type of cursor, called a tailable cursor, can be used with capped collections. This cursor was named after the `tail -f` command, and does not close when it finishes returning results but continues to wait for more to be returned, returning new results as they are inserted into the capped collection.


Vaadin is a Java framework for building modern web applications that look, great, perform well and make you and your users happy.

Vaadin is an open source Web application framework for rich Internet applications. In contrast to JavaScript libraries and browser-plugin based solutions, it features a server-side architecture, which means that the majority of the logic runs on the servers. Ajax technology is used at the browser-side to ensure a rich and interactive user experience. On client-side Vaadin is built on top of and can be extended with Google Web Toolkit.


One of the most prominent features of Vaadin Framework is the ability to use Java (using a Java EE platform) as the programming language, while creating content for the Web. The framework incorporates event-driven programming and widgets, which enables a programming model that is closer to GUI software development, than traditional Web development with HTML and JavaScript.

Vaadin Framework utilizes Google Web Toolkit for rendering the resulting Web page. While Google Web Toolkit operates only on client-side (i.e. a browser’s JavaScript engine) – which could lead to trust issues – Vaadin adds server-side validation to all actions. This means that if the client data is tampered with, the server notices this and doesn’t allow it.

Vaadin Framework’s default component set can be extended with custom GWT widgets and themed with CSS.

From application developers point of view, Vaadin is just one JAR-file that can be included in any kind of Java Web project developed with standard Java tools. In addition, there are Eclipse and Netbeans plugins for easing the development of Vaadin applications as well as direct support of (and distribution through) Maven.

Vaadin applications can be deployed as Java Servlets to any Java server, including Google App Engine. Applications can also be deployed as Portlets to any Java portal, with deeper integration to Liferay Portal.

Apache ActiveMQ

Apache ActiveMQ is an open source (Apache 2.0 licensed) message broker which fully implements the Java Message Service 1.1 (JMS). It provides “Enterprise Features” like clustering, multiple message stores, and ability to use any database as a JMS persistence provider besides VM, cache, and journal persistency.

Apart from Java, ActiveMQ can be also used from .NET, C/C++ or Delphi or from scripting languages like Perl, Python, PHP and Ruby via various “Cross Language Clients” together with connecting to many protocols and platforms. These include several standard wire-level protocols, plus their own protocol called OpenWire.

ActiveMQ is used in enterprise service bus implementations such as Apache ServiceMix, Apache Camel, and Mule.

ActiveMQ is often used with Apache ServiceMix, Apache Camel and Apache CXF in SOA infrastructure projects.


Mule is a lightweight enterprise service bus (ESB) and integration framework. It can handle services and applications using disparate transport and messaging technologies. The platform is Java-based, but can broker interactions between other platforms such as .NET using web services or sockets.

The architecture is a scalable, highly-distributable object broker that can seamlessly handle interactions across legacy systems, in-house applications and almost all modern transports and protocols.

Some of the key features of Mule are:

  • Pluggable connectivity, for around 50 protocols including JMS, JDBC, TCP, UDP, Multicast, HTTP, servlet, SMTP, POP3, file, XMPP.
  • Message routing capabilities
  • Deployment topologies including ESB, ESN, “hub and spoke” and client server
  • Web services and WS-* support using Apache CXF, Xfire, Axis and Glue
  • Integration with JBoss and other application servers
  • Spring integration
  • Transformation layer
  • Integrated security management

About Sanju
I am Software Programmer. I am working in JAVA/J2EE Technologies.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: