Get started with MongoDB in windows with .NET

MongoDB is currently one of the most popular NoSQL databases. The idea behind this post is to provide a concise document that will help you get started with MongoDB on Windows with .NET.

Follow the step by step guide below to get started:

  • Download the database server from It’s available for 32 and 64 bit machines. Note that the 32-bit builds can store maximum of around 2 GB data. Refer to for details.
  • The 32-bit installation is of around 18 MB size. It is a zip file which contains a bunch of executables.
  • To start the server:
    •  Create a batch file with ‘mongod.exe –dbpath “C:\\data\\d”. Here ‘dbpath’ specifies the location of the database as “C:\data\db” and any newly created database will be placed at this location.
    • Executing this command will start the server and this is how it  is shown in the console.
Now, let’s take a look at the available drivers in C# .Net for MongoDB. The official driver can be downloaded from and its details are at You can also get drivers with fluent interface on top of this official driver from I found another driver-NoRM at which uses C# classes. MongoVUE is the IDE available for windows.Sample Application:

  • Create a console application. This will keep the application free from any other code and everyone can relate to it easily.
  •  I will be using the NoRM driver in the sample application.  Add the NoRM.dll in your project reference. Add this line along with other statements for using a library: using Norm;
  • To obtain a handle to the database, a static method is available which needs a connection string to the database. Use the following code: IMongo db=Mongo.Create(“mongodb://localhost/MongoTest”); Here the ‘MongoTest’ is the name of the database and I am using the server on my local machine.
  • Assuming that the server is up and running, this call will return a valid handle to the ‘MongoTest’ database. This is valid even if the database is not created yet. A subsequent call to save any value in it can create a new database. Only calling this method will not create a database.
  • So, let’s assume that we have employee data to be saved. This is how you save an object of employee class: db.GetCollection().Save(emp); ’emp’ is the object of class ‘Employee’ and executing this line will actually create a database (if not created already). It will also create a new collection name ‘Employee’ with one entry for ’emp’ object.
  •  To get a list of employees: var employees = db.GetCollection().AsQueryable().AsEnumerable();
  • To delete an employee: Employee emp = db.GetCollection e.Name == “emp1”).SingleOrDefault(); db.GetCollection().Delete(emp);
Yes, that’s all you got to do to get started with MongoDB from .NET. The full application is available at and this is the full page of program.cs file to consolidate:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Norm;namespace MongoTestConsoleApp
public class Employee
public ObjectId Id { get; set; }

public string Name { get; set; }

class Program
static void Main(string[] args)
Employee emp = new Employee();
emp.Name = “emp1”;

IMongo db = Mongo.Create(“mongodb://localhost/MongoTest”);


Agile Database Migration Tools for Java

Agile methodologies of software development require a major shift in approach towards database management. The reason is requirements are never really frozen during agile development. Though changes are controlled, the attitude of the process is to enable change as much as possible. This change can be in response to the inherent instability of requirements in many projects or to better support dynamic business environments.

Thus agile development needs tools to enable and support evolutionary database design, along with solving problems like porting database schema changes on an instance with critical data.

Ruby on Rails, which is designed for agile development, provides built-in capabilities to cope with this problem, in the form of Active Record Migration. However, Java currently doesn’t have a solution of that pedigree. There are a few viable alternatives though, the most popular among the current breed is Liquibase. I will present an evaluation here which might help you choose the best tool.

Liquibase: Here are my observations, from trying to integrate it with a Spring, Hibernate3 annotation based configuration project. Liquibase is described as a substitute for Hibernate’s hbm2ddl. It can be integrated with an existing project in a few simple steps. The advantages are Spring integration so dev environments have updated databases. Secondly version management – changesets are ID-ed and stored in a table after being applied to a database and changelogs can be written in SQL.

Liquibase gives 2 ways of writing migrations, XML based and SQL based. The biggest disadvantage of Liquibase is the inability to write java-based migrations. This lead us to a search for a solution that provides most of the features present in Liquibase, as well as support for Java-based migrations.

c5-db-migration: c5-db-migration supports migrations in Groovy, as well as migrations from within the application i.e. it provides APIs for migrations. However it doesn’t support migrations written in Java. There is no multiple schema support and it isn’t present in maven central.

Migrate4j: This tool supports Java migrations and it also provides an API for migrations. Disadvantage is that it doesn’t support even plain SQL migrations and is terribly short on features (no auto creation of metadata table, no multiple schema support and no maven support).

Flyway: Flyway offers cleaner versioning than Liquibase, migrations can be written in Java as well as SQL, and it supports auto-discovery of migrations in project packages.  However the one missing feature is that it doesn’t support rollbacks, though it is more of a design choice taken by Flyway developers.

After careful evaluation of each of these tools we decided to go ahead with Flyway for the project, and it has been great so far.

Building Web Services with JAX-WS : An Introduction

Developing SOAP based web services seem difficult because the message formats are complex.  JAX-WS API  makes it easy by hiding the complexity from the application developer. JAX-WS is the abbreviation for Java API for XML Web Services. JAX-WS is a technology used for building web services and clients that communicate using XML.

JAX-WS allows developers to write message-oriented as well as RPC-oriented web services.

A web service operation invocation in JAX-WS is represented by an XML-based protocol like SOAP. The envelope structure, encoding rules and conventions for representing web service invocations and responses are defined by the SOAP specification. These calls and responses are transmitted as SOAP messages over HTTP.

Though SOAP messages appear complex, the JAX-WS API hides this complexity from the application developer.  On the server-side, you can specify the web service operations by defining methods in an interface written in the Java programming Language. You need to code one or more classes that implement these methods.

It is equally easy to write client code. A client creates a proxy, a local object representing the service and then invokes methods on the proxy. With JAX-WS you do not generate or parse SOAP messages. Thanks to JAX-WS runtime system that converts the API calls and responses to and from SOAP messages!

With JAX-WS, web services and clients have a big advantage which is the platform independence of the Java programming language. Additionally JAX-WS is not restrictive: a JAX-WS client can access a web service that is not running on the Java platform and vice versa. This flexibility is possible because JAX-WS uses technologies defined by the World Wide Web Consortium – HTTP SOAP and the Web Service Description Language or WSDL. WSDL specifies an XML format to describe a service as a set of endpoints operating on messages.

Three most popular implementations of JAX-WS are:

Metro: It is developed and open sourced by Sun Microsystems. Metro incorporates the reference implementations of the JAXB 2.x data-binding and JAX-WS 2.x web services standards along with other XML-related Java standards. Here is the project link: You can go through the documentation and download the implementation.

Axis: The original Apache Axis was based on the first Java standard for Web services which was JAX-RPC. This did not turn out to be a great approach because JAX-RPC constrained the internal design of the Axis code and caused performance issues and lack of flexibility. JAX-RPC also made some assumptions about the direction of Web services development, which turned out to be wrong!

By the time the Axis2 development started, replacement for JAX-RPC had already come into picture. So Axis2 was designed to be flexible enough to support the replacement web services standard on top of the base framework. Recent versions of Axis2 have implemented support for both the JAXB 2.x Java XML data-binding standard and the JAX-WS 2.x Java web services standard that replaced JAX-RPC(JAX-RPC: Java API for XML-based Remote Procedure Calls. Since RPC mechanism enables clients also to execute procedures on other systems, it is often used in a distributed client-server model. RPC in JAX-RPC is represented by an XML-based protocol such as SOAP). Here is the project link:

CXF: Another web services stack by the Apache. Though both Axis2 and CXF originated at Apache, they take very different approaches about how web services are configured and delivered. CXF is very well documented and has much more flexibility and additional functionality if you’re willing to go beyond the JAX-WS specification. It also supports Spring. Here is the project link:

At Talentica we have used all the three implementations mentioned above in various projects.

Why CXF is my choice?
Every framework has its strengths but CXF is my choice. CXF has great integration with the Spring framework and I am a huge fan of Spring projects. It’s modular and easy to use. It has great community support and you can find lots of tutorials/resources online. It also supports both JAX-WS and JAX-RS specification but that should not be a considering factor while choosing CXF. Performance-wise it is better than AXIS and it gives almost similar performance when compared to Metro.

So CXF is my choice, what is yours?

Event: Node.js Over the Air!

Over the Air sessions at Talentica are technical workshops where a bunch of developers roll up their sleeves, tinker around with new platforms/technologies to learn together, gather new insights and get a healthy dollop of inspiration. Last week we had an “Over the Air” session on Node.js.

Node.JS is a server side javascript interpreter that changes the notion of how a server should work. It’s goal is to enable a programmer to build highly scalable applications that handle tens of thousands of simultaneous connections on a single server machine. Node.js is one of the most talked about technology today. To know how it works really, we picked it up for this Over the Air session.

Once we gathered up, it took a little while for some of the participants to get used to the event-driven programming style. Pretty soon, we were all working together on building a cool chat app. By the end of the day, we had a fully working version of a chat room app in which any user can enter the chat room by simply entering a nickname. Subsequent entries are posted to all logged in users. The right side pane shows all the logged in users.

This is a fairly decent basic version. Going forward, we plan to enhance the User Interface so that people can play games using the chat app; integrate the UI with the chat engine and enable users to be able to challenge each other to play while chatting.

First Impressions
Node.js is an excellent option for interactive apps. I will not hesitate to use Node.js in products that require interactive functionality like chat, auctions, online multiplayer games. One can use Node.js to suit a part of the product than building the complete product on it.

The fact that we can code server side with Javascript should make Javascript developers jump with joy. Code reuse between client and server side might actually be possible!

On the negative side, I am not sure if the event programming model is a good one on the server side. It might lead to spaghetti code with callbacks all over the place. Another thing is that though the community is very active and plug-ins are being developed at a rapid pace – it is still not a tried and tested technology at this moment!